Gearswap And New Timers

Well, I know there are.
But I am afraid that it will be one hell of a job to implement it in my current gearswap.

At this moment the only thing we can do is keep our fingers crossed and hope in Byrth's benevolence <3

When is the next free login period? I can try to fix it then.

15th - 25th

I just attempted to log in to make sure they hadn't banned me or anything, but I keep getting POL-1160 errors (on two different computers on two different networks both of which used to work and haven't changed afaik). Can anyone else log in to POL right now?

I just managed to get in after did a flushdns in cmd.

Didn't work for me. Could just have been random luck for you. 1160 is their excessive traffic error, so it could be that their POL servers are getting DDOS'd right now.

There seem to be quite a few people experiencing this from all over the planet right now.
They mentioned something about a hardware malfunction earlier which they said they fixed.

I could get in myself about an hour ago as well, but I could just have been lucky.

I logged in 10 minutes ago. Seems is working now.

Seems timers all out of whack indeed. Even on wards it's goes back to non-pet idle for me.. and my favor set is completely ignored.

Any news about this guys? Is it working for you or still the same issue?

Did Salvage last night after GS was fixed, the problem's still there.

Did we at least found what is causing it?
And what is happening?
Is GS swapping too fast? (BP executed in Idle/Perp) or too slow? (BP executed in BP- gear)

¯\_(ツ)_/¯

When I do //gs load SMN.lua WITHOUT a pet summonned... my perp set shows up again... however it gets *** zoning with pet active.

I notice that when i preform a BPR and have showswaps on it goes from precast to aftercast to petmidcast to pet aftercast is the aftercast after precast a normal process or do i maybe have a problem with my lua.

Is there also anyway that you can delay pet aftercast so petmidcast set gets held on longer as a temp fix for the timers issue?

Not sure if Aftercast (player) should be procced or not by GS when you execute a BP.
What I'm sure of is that if your Lua doesn't have errors, Aftercast (Player) should do absolutely nothing when the action executed is a BP Rage or a BP Ward.
As long as Aftercast performs nothing, then even a process like this should be fine.

Precast (Player) > Pet_Midcast > Aftercast (Player) > Pet_aftercast

As long as Aftercast does nothing, you'd still remain in your Pet_Midcast gear.

I wonder, will Rooks be the mantainer of Gearswap as well, now that Byrth got busy?
If so maybe we could try to summarize this issue and let Rooks know about it so he can work on it and so we can do our best to help him solve it?

Typically (this depends on which order SE sends packets in) it occurs pretarget, precast, midcast, after cast, pet_midcast, pet_after cast, but I did not trust it so I have my own SMN lua ignore aftercast swaps if I just used a BP.

Hopefully the campaign is still going on tonight. I will try to lognin and take a look at this again. Last time I made it to my moghouse and was like, "Running around is such a chore without clipper q.q; /logout"

Gearswap itself is functionally complete; I'm happy to fix bugs if need be (like after a patch), but it doesn't really need a maintainer in the way that something like Organizer (which still has room to grow) does.

That is correct Rooks and I agree with that, sorry if I implied I meant anything different.
I'm no longer a programmer myself, but this "bug" SMNs are experiencing looks very tricky because we don't even know what's happening yet, would need more detailed tracking tools to see what causes the issue.

All that we noticed is that BPs get executed (midcast) with a wrong set. Which exactely we don't know, neither why it happens.
It's not 100% either, but happens often and tends to happen more in laggy (instances) situations.


It sounds really really really tricky to solve honestly. At the same time it's something really vital, as a SMN you cannot afford to execute BPs with the wrong set so often.

Oh, I'm not doubting the need for a fix. If Byrth doesn't find something, I'll see what I can do.

Honestly, given the rapid-fire timing of the packets in that sequence, Byrth's workaround (don't call aftercast after BP) might be the only reliable answer. You'd just call aftercast() in pet_aftercast and roll with it.

I have these lines in my aftercast (player)


So even if Aftercast (player) gets executed, no matter when, it should perform no action at all if the current spell is a BP.
As far as I know it always worked for me until when SE decided to change the activation timer of BPs (altough I'm not really sure that's the source of the issue)

So before I get home to try, just change this:


to This?

[edit]
Tried several combinations, didn't solve the problem.

Err, I don't know how that block could ever trigger. Something can't be both BloodPactRage and Ward, and that's what you're checking for.

[Edit: I am dumb and this is not perl]

That rule processes when he doesn't use a blood pact of any kind. It ~= means Not equal.

Basically, it makes it so aftercast doesn't do anything if he is using a bloodpact.

Derp. I was reading that as =~ (which is perl's match operator).

Yep exactely. This is a rule I created loooong time ago, but it was just to say that no matter when or where my Aftercast (player) gets processed by Gearswap. Regardless of that Aftercast should perform no action if what I used is a BP.

Which leads me to think that the issue we're experiencing (BP going out with a wrong set) has nothing to do with Aftercast (player) function.


The hypothesys I made some time ago are:
1) Too early - GS executes Pet_Aftercast too soon. That means your BP goes off with whatever set you've put in Pet_Aftercast.
2) Too late - GS equips Pet_Midcast gear too late. That means the BP goes off with the Precast (Player) gear you've set up for BPs.
3) ??? Can't think of any other source causing this.


As I mentioned before we do not know what's happening. All we're seeing is our damage being much lower than it should, sign than it got executed with the wrong gear.

Again I'm almost positive this is not a problem with Gearswap, it's a problem with Mote's includes.

I'm not using the Mote includes, and my BPs always execute in the correct gear. 100% of the time as far as I can tell. (Aside from the one case I pointed out earlier where pet_midaction() doesn't report the correct status, most likely due to client-server latency.)

Nope.
Me and Lewyo use our own luas which we built on our own, each of us his own file.
Lewyo took a lot from Acacia's lua whereas mine was built completely from zero.

I've never used any of Mote's luas for any of my jobs.
Not saying it has to be 100% GS's fault, but given how many people reported that it works flawlessly with the game's built-in system I'm leaning to say that yes, it's likely this has something to do with GS, one way or another.