Gearswap Help Thread!

[holyshoot]

How do I get gearswap to swap back into my run speed boots on my thief when I am done fighting? Right now it only goes into them in town. I am using kinematics gearswap job file for my thf.

[Motenten]

Make sure they're part of your idle set (sets.idle, or sets.idle.Field, depending on what you've set up). It sounds like you only included them in sets.idle.Town.

[holyshoot]

Make sure they're part of your idle set (sets.idle, or sets.idle.Field, depending on what you've set up). It sounds like you only included them in sets.idle.Town.

That was pretty much it. Now is there a way to make it so the game will equip my thfs knife for the first hit on every mob if I want it to and then switch out to my real dagger?

[JSHidaka]

Why would you want to reset TP on every mob? Plus TH can be capped w/o tk

[Sechs]

Afaik it is done.You need to put:

if midaction() then
return
end

In aftercast.

Ah yes, those are the lines I already had but I commented them when me and other people reported the "issue" and you said you started working on the thing.
Just wanted to know if I had to change something in my luas or not.
So I guess the random lock-up thing shouldn't happen anymore now, or at least less frequently? (tbf it wasn't that frequent to begin with)

Thanks a lot for your work!

[Sechs]

Wait, I just got back home to uncomment the midaction() lines in my relevant luas and noticed I placed those 3 lines of code at the beginning of PRECAST, not aftercast.
You sure I have to put it in aftercast or was it a typo?
It made more sense to me to put them in precast, and long time ago when I asked about it I got suggested to put 'em in the precast.

The reason why I asked for such a solution back then was to solve an issue of finishing casting spells with wrong sets.
Example: I'm casting Blizzard V, while the spell is being cast and I'm in my midcast set, I accidentally press another spell macro, say Stun, ending up casting Blizzard V in my Stun's precast or midcast set.
To avoid this I got suggested those midcast() lines in my precast. They worked just fine except the occasional lock issue.
How would putting them in aftercast help with this? I don't get it.

[kenshyn]

I been using in precast myself stops other spells from changing my gear while not finished with the action running.

[JSHidaka]

yea, in aftercast wont prevent it from changing the gear to precast/midcast if you spam a macro/action.
But in theory you can make your own "midaction" creating a bolean(lets say casting), then the precast function would looks like:

function precast() = {
     if casting == false then
         casting == true
         -- and everything that would go normally in precast
     else
         --You are casting something so you dont want any gearswap/action
       cancel_spell() -- maybe?
       return
     end
}

then inside aftercast
casting == false

[dlsmd]

yea, in aftercast wont prevent it from changing the gear to precast/midcast if you spam a macro/action.
But in theory you can make your own "midaction" creating a bolean(lets say casting), then the precast function would looks like:

function precast() = {
     if casting == false then
         casting == true
         -- and everything that would go normally in precast
     else
         --You are casting something so you dont want any gearswap/action
       cancel_spell() -- maybe?
       return
     end
}

then inside aftercast
casting == false

you would do it like this

function precast(spell)
	if casting then
		cancel_spell()
		return
	end
	...
end
function midcast(spell)
	casting = true
	...
end
function aftercast(spell)
	...
	casting = false
end

or

function precast(spell)
	if casting then
		cancel_spell()
		return
	end
	...
	casting = true	
end
function midcast(spell)
	...
end
function aftercast(spell)
	...
	casting = false
end

ware ... is every thing you want in the function

this will not work if you have any returns in the aftercast function

[JSHidaka]

yup, something like that, just got that idea reading about the "problem"... so not sure if it will really works or do what Sechs wants,

[Byrthnoth]

The problem is:

Precast JA -> Midcast JA -> (Precast JA2 -> Midcast JA2 -> Aftercast JA1) -> Aftercast JA2

Because the minimum time between JAs is 1 second, this is possible when spamming JAs. The issue is that equipping Aftercast JA1 after Midcast JA2 will eliminate any effect on the JA that the midcast might have had, like taking off BRD AF2+4 body when going Nightingale -> Troubadour. If you use the code that I wrote in aftercast, then midcast would be true during "Aftercast JA1" and it would stop any equipment changes from happening, thus saving Midcast JA2.

[dlsmd]

i would never use midcast on ja's because thay would never have enuf time to equip a full set of gear

[Sechs]

I don't use Midcast on JAs either, just Precast and Aftercast, but this doesn't change the fact that the issue Byrth described could have happened as well.
I see you guys do remember my issue with BRD body randomly not equipping :D I'm moved lol, that issue was exactely what Byrth described, minus the midcast.

In all honesty though, I wasn't thinking about that now. I long solved that issue with a "trick", I found two tricks to be working. One is to use /raw commands and manually equip gear, the second method is to put BOTH pieces in BOTH sets (so my sets.precast['Nightingale'] = my ['Troubadour'] one) and then I manually excluded those 2 JAs from Aftercast. I.e. no aftercast will be activated after the use of any of those 2 JAs.
Both methods work 101% as far as I can tell, but I like the second more.


The reason why I made my previous post wasn't about that BRD issue, it was about another issue I found with Midaction().
Basically with those lines in my precast I was randomly getting "stuck" in a set, and Gearswap wouldn't process any command I were to give him for a few seconds (commands executed from the menu worked instead).
After me and a few other people posted about that thing, Byrth said he knew about it and that to solve it he would have to do some major rehaul to the Midcast() function.
Following that post from Byrth I just temporarily commented those midaction lines from my luas .
This is why this morning I asked Byrth what was the status of his work on Midaction(), I wanted to know if I could uncomment them or not yet :D

[Byrthnoth]

AFAIK it works. No one has presented me with a case (aside from dropped packets) where it fails.

[Sechs]

AFAIK it works. No one has presented me with a case (aside from dropped packets) where it fails.

Let's go back to square 1.
I was talking about THIS thing and the following posts.
You mentioned you would be working on it, at least on -dev.
Did you manage to finish your reworking of it? Is it just on dev or live as well?

Does using midaction() still produce the same results me and other people reported? (in which case it would be safer to use a solution such as that suggested by JSH)
Or is the "issue" solved? If it is, what do we have to do? The same lines we've been using or we need to adjust something somewhere?
If so what?


I still have to understand why this "midaction" staying to true happens. You mentioned packet loss but I had the impression it happens when I got interrupted very close to the end of my casting being done.
I didn't manage to perfectly understand it, but somehow I got the impression it always happened when I incurred in some form of interruption of my castings.

[Byrthnoth]

I replied to your original question about it with this:

Afaik it is done.You need to put:

if midaction() then
return
end

In aftercast.

[Byrthnoth]

Midaction iterates over the command registry and checks to see if any of the entries have their midaction flags set. If they do, then it returns true. If they don't, then it returns false.


The command registry works like this:
1) When you attempt an action with all the necessary parts (valid ability prefix, name, and target), GearSwap creates an entry in its command registry for that action indexed by a timestamp with midaction=false.
2) When GearSwap injects that action, it sets midaction to true for the command registry entry.
3) When Aftercast is triggered for that command registry entry, midaction is set to false.
4) If a valid Aftercast (not interruption) is triggered for any action, midaction is set to false for all entries in the command registry. (Options #1/#2 below)

The problem is the connection between lines 2 and 3/4. Lines 1 and 2 can't fail to connect and wouldn't be problematic even if they did fail. The problem is when an action is injected and GearSwap either does not receive the resulting packet (dropped packets) or cannot recognize it as a result. These are the current conditions for that:
* If an action packet is returned that indicates completion and would generate a message containing the action's name (like Byrth casts Fire II\nThe monster takes 3000 damage.) or other identifying information (generally invisible) then the command registry is searched for the most recent instance of that spell, and that entry is passed in to aftercast.
* If an action/action_message packet is returned that indicates completion but is ambiguous about what action it refers to, the most recent entry is passed in to aftercast.
* If an action/action_message packet is returned that indicates interruption, the interruption flag is set and the most recent entry is passed in to aftercast.
* When anything dies, the command registry is searched for entries targeting that player/monster, their interruption flag is set, and they are passed in to aftercast.
* When you are slept, petrified, terror'd, stunned, etc. (things that prevent actions), the command registry is emptied and its contents are passed in to aftercast with the interruption flag set.


As far as I know, the only way right now to break the connection between #2 and #3/4 for players is for the server to drop the result packet from a given action. For pets, it's as simple as running out of range (30'+) between pet_midcast and pet_aftercast (or dropping the packet). Any time that you've been stuck in an animation for much too long, the server has probably dropped or not sent the packet. Like how Wyverns start "readying" a breath and never finish if you kill the monster with a melee swing before they get it off.

[Sechs]

Wow, thanks for the insight, think I have a better understanding of it now :D

[JamesRay]

I am making the switch to gearswap from spellcast but ran into a problem. I still have spellcast loaded in order to use shortcuts like //cure4 etc
but when I do these shortcuts gearswap does not recognize it and change gear. Is there possibly a new plugin that mimics spellcast for easier spells or a fix to gearswap not recognizing the commands?

[dlsmd]

I am making the switch to gearswap from spellcast but ran into a problem. I still have spellcast loaded in order to use shortcuts like //cure4 etc
but when I do these shortcuts gearswap does not recognize it and change gear. Is there possibly a new plugin that mimics spellcast for easier spells or a fix to gearswap not recognizing the commands?

the addon shortcuts