Annoyed By Lags "killing" Precast/midcast In GS

id just get a better PC to fix the issue. i'm sure its your PC not GS

Edit: Oh you're Cylas, nevermind, removed my huge blurb. You already know about my Lua. :)

That said, if it's not working, I'd be surprised if it's the computer. The only thing that would prevent it from working is if your PC never gets the packet about your pet readying BP. I think lag is a more likely culprit than the PC itself. Is your connection really slow? Like over a full second of lag slow? BP ready time is 1.25 sec. If your computer doesn't receive the packet fast enough, Gearswap won't process the pet_midaction function which is where BP Damage gear tends to lie.

It's likely not his PC, it's SE's servers. BP mid set is typically activated when the server says your avatar readied the BP, if communication is not reasonably fast in both directions it won't be on in time.

It's not like player pre/midcast, where it's all sent out in one block and immune to lag issues.

Yeah, if you just do a <wait 1> after your BP and then equip your BP damage gear with /equipset or something, that should generally work regardless of lag.

Either that, or change to a faster ISP. Lag has definitely been increasing on the servers, but it's not at the point yet where this should be any kind of common problem. At least, not in my experience. I'm blessed with living in the Pacific NW though, which has a pretty straight shot to Japan in terms of internet connectivity.

hey cylas, so I take it switching to pergatory´s lua didn´t change anything for you?
I´ve been in the same omen as him yesterday, on a bad pc with a shitty connection, and I had the exact same problem. unloading gearswap and fulltiming my bp set upped my fc damage from 6k to 40k average. on my regular rig, it´s not as bad but it still happens, only in omen tho (didn´t go smn to dynamis-d yet but I can imagine it´s the same there).

I get it frequently. Its painfully obvious in omen when thunderspark cleaving mobs. A missed ts will do 3k opposed to a geared 12k.

Time for y'all to start making noise on the official forums about the degrading server performance.

Surely the money they're getting for subscription costs could afford us some better servers. I've joked with my friends that I'm pretty sure they're down to just 1 gerbil powering the whole FFXI server farm now. If that gerbil ever dies, we're screwed.

Omen is especially bad. I get a 1-2 second delay with only 6 people sometimes. Not sure what causes it.

It seems like it is dependent on who takes you in to Omen. I have crappy DSL and one time my wife was watching Netflix. When I entered I lagged so bad no mobs were in the zone. Since I entered my whole group into Omen, the mobs weren't present on any of my party members screens. As soon as my wife turned Netflix off the mobs showed up on everyone's screen.

I don't really buy that because the lag has gotten drastically worse over the past year or so. Even after Omen/Ambu came out, there was no lag at all.

It was only a few months after Omen was released that there began sudden massive lag spikes in Escha/Omen. It was an immediate change, day and night, for those who were active at the time. It was pretty clear something broke and SE even did an announcement that they were fixing some hardware issues in March of 2017. I think they actually said they were replacing a server.

Whatever they did alleviated the stress partially, but it never actually went away. Since then it's just been limping along, fluctuating between bad and worse.

They probably just don't want to invest in a dying game, and replaced whatever broke with a smaller/cheaper version that is struggling to keep up. They probably don't even realize how badly it's affecting the game. After all, this is the same company that didn't bother to test the AV mechanic on something other than a local network connection to the server to see if it's even possible for us mortal players to perform.

Happens to me too, in lagged instances more than in not lagged ones, but it still happens even outside.

This was reported by me and multiple other SMNs ages ago to Byrth, who gave it a LOT of work but couldn't reproduce the issue.
I just gave up trying to resolve it honestly...
Altough if you're ultimately annoyed by that using the in-game sets system completely solves the problem.

Afaik that issue doesn't happen with Ashita, or at least nobody ever reported it.
Which, in itself, doesn't really mean anything I guess :x

Personally I don't play SMN often enough for me to bother, but if I were and wanted to use Gearswap, I would simply use Gearswap to handle like 90% of my SMN stuff, but use in-game equipset to handle precast and midcast sets for BPs, still using Gearswap for Aftercast to return to whatever idle set I want according to situations/triggers etc.

If using ashita's petskill functions as it's designed, it will still happen. Same issue as gearswap, can't change to BP gear if you don't get told the BP is starting. This is all on SE.

You can use something like:
<command delay="800">/ac set VoltStrike 2</command>

in your ja section to reliably get your 'mid' gear on. For conduit, I still strongly advise not using Ashitacast or Gearswap.


For other spells/abilities, ashitacast won't mess up like gearswap does, because the resent packets still get correctly adjusted.

Fwiw, the actual GearSwap issue with people not swapping instant cast gear properly was simply because packet injection is threaded off, introducing a race condition.

The original handling was
1) the action was injected
2) the logic performed
3) the equipment injected,

There was a small chance that the action and equip ended up in two separate UDP packets, moreso if the user had Too Much Logic (or lots of string building, table rehashing, anything that takes a lot of time in Lua). I switched the order of 1 and 2 awhile ago so it happens significantly less (though since there is a race condition the chance is technically non-zero, but I doubt most CPU would ever generate this result).

But yeah, no reliable way to handle a pet midcast from the pet packet. The best thing you could do would be to have handle it in your aftercast for the BP JA*.

*Edited some weird brain logic that happened.

Had the same idea here before the edit. I haven't been on SMN since to test in a laggy enough environment, but adding this block to a mote-based GS could the trick, as far as swapping to BP gear on the JA's aftercast timing:

Been traveling a lot and find myself overseas a fair amount on laggy internet now. This has made my smn almost unplayable except for defensive roles and af/ac situations. Did the above solution work out for people? Just hoping there's a way I won't have to rewrite all macro's. Something to trigger the correct gear in a timed manner if the packet doesn't come through to initiate it?

I think the things in this thread have been found to mitigate the problem in some situations, but if your lag is really bad they don't help.

It's funny you bring this up because during that recent CenturyLink outage a couple weeks back, I had some nasty lag and it was the first time I've experienced this problem myself. I have some ideas for how to make a better lag compensation mode, I'll try to have it posted in a few days.

I've got a question for Cair, Comeatmebro or anybody else competent with packets/actions flow.

This is what should happen when things work correctly:
I've always assumed the error was happening in the last steps, with Step #7 being executed before step #6 (because of a packet loss?) meaning the pet BP would complete with Player aftercast (idle) gear.

From Cair's last post in this thread instead it seems to me that the problem is more about GS not noticing step #4 for whatever reason, hence skipping steps #5 and #6, meaning that the BP would complete with BP precast gear?

Please enlighten me because I might have misunderstood Cair's post.
If I remember correctly what Comeatmebro said in another thread this doesn't happen with the in-game equipset functions NOT because they are more accurate than GS/Ashita packet injection, but simply because in-game macros have fixed /waits in seconds.
The in-game system doesn't "wait" for a "Pet readies XX bp" line. It just waits X seconds and simply executes actions flawlessly no matter if a "pet readies" packet is lost or not.
This is the reason why BP firing with wrong set is so rare when using in-game macros, even in zones with a huge amount of packet loss like Omen and Divergence areas.

If Comeatmebro's explanation is correct (and it makes a lot of sense to me) then in theory you could be able to replicate this even with GS/Ashita, simply creating custom rules that avoid the usage of Precast/Midcast/Aftercast logic but simply execute actions in a sequence with fixed /waits in between.
I do that for /party messages during some of my abilities on some of my Luas, should be pretty simple to do the same with equip and /ja commands.

Cair's post is in regards to basic pre/midcast failures. I haven't seen their code and can't comment firsthand, but the takeaway should be that they've been minimized or eliminated at the time of his post. I am not sure if it is accurate or not.

As far as pet BP, in normal conditions using static delays will eliminate the issues. You are correct that using a wait corrects it, because it doesn't matter if the pet readies packet is received or not.

However, in light of more recent observations, I would also like to comment that the issues are worse than they were at the time of this thread. Particularly in divergence, at times the server issues go beyond simple packet loss and you get response times well into the seconds. Waits may be more accurate in this case, but if the server is taking seconds to respond they still won't necessarily be accurate enough.

In short, your observations are mostly correct with the caveat that periods of extreme lag in dyna-d will still ruin even static waits.

I've rarely had that issue pre-omen. I guess it was occurring, but it was rare. It generally is still rare for me in open world content. Maybe in Incursion I dunno but I never used SMN much there.
It started becoming something I would definitely notice in Omen, it was quite clear when you were AoE cleaving with Ramuh.

In divergence the issue reached levels beyond any acceptability. So much that it started to become an issue even for other jobs, it's insane.

I wonder what is the real cause of it. Their "instancing" servers becoming over-stressed? The instancing tech used for Divergence being different from all others?
No clue but Divergence is insane, and if you have multiple groups in the same zone it becomes so bad it kills my will to play at all honestly.


Anyway, thanks for your insight. If I ever come up to unlazy myself I will just make custom rules for BPs on SMN to make so there are static waits instead of using the default Pre/Mid/Aftercast logic.

Something causes exponential performance loss in their instanced servers, I assume related to IPC between the instance and the host server. I've mentioned before, but I observed tells and linkshell chat being delayed by extreme amounts(14 minutes once!) in salvage back when everyone was doing arrapago remnants to exploit boss repop.

Note that this is not likely a hardware problem, given during the 14 minutes other actions have reasonable(<1s) latency. It is more likely a poor synchronization mechanism is delaying proper response time. Note that dynamis has to sync more often with the main server, because everyone's inventory is technically updating every time you get RP. If they do a seperate synchronization for every single time that happens, rather than a single synchronization per mob kill, it would make perfect sense for the lag to be so horrible.

Note that this doesn't mean you only lag when mob dies, if correct. Other people taxing the same server the same way could cause similar spikes, so unless you are the only group using that instance server at the time, it would be very hard to confirm or deny.

The way they handled RP (which is unique to Divergence zone) is a good chance on requiring an excessive amount of update cycles creating such stress and, as an ultimate consequence, the sheer amount of packet loss. Good catch on that!!

It might be similar with Omen (granted the issue seems to be less severe there) because of the hidden counters/omens the server has to take account for each monster you kill.

These are all additional things that weren't thought of when they initially created their internal communication/syncing protocols and, in addition to god knows how many other things added to that, it might as well be the cause of what we're experiencing.


I agree it's more a software/netcode/syncing issue more than a pure hardware one.
I can't tell of course but given the amount of times they have updated their hardware I assume they're probably more powerful than the game needs. Pretty confident myself it's not a pure HW issue but something more among the lines of the other stuff we mentioned.

Counters are only tied to omen itself, the server doesn't have to update them constantly. The main server only needs to know a value to save/load when the run ends, and when cards are awarded. This doesn't necessarily mean they don't constantly sync them, but it's not necessary to do so, so they likely don't.

RP are a different beast, because you don't want to let players get them roll backed. It's further complicated by the instance server needing the information immediately due to stat changes on the gear.