ThornyFFXI/LuAshitacast

Spamming cast with interimcast does not equip final set

Closed this issue · 6 comments

If HandleMidcast is using InterimEquipSet and you attempt to cast a spell while you're already casting a spell HandleMidcast will never equip your final gear set. I've tried various methods of disabling HandleMidcast while a spell is being cast but it's very messy and doesn't thus far work. Is there a recommended method to circumvent this issue?

I don't consider this an issue. If you try to cast a new spell, the new spell should take priority which removes the state from the old spell.

It is possible to add additional state tracking to prevent this, but I don't think it is beneficial because the retail servers frequently fail to send spell completion packets. In this case, you could end up failing to swap for the second spell, even though the server knows the first has already completed.

Is there any reason that you are frequently trying to cast another spell before the last has finished? I don't get it.

Casting spells in quick succession, trying to cast a spell the moment it comes off cooldown, or a simple fat finger can all lead to this issue. It feels very fragile. It's certainly not crippling but it's very noticeable and requires you ease up on the gas, so to speak.

Does the server frequently fail to send begin casting spell packets?

The server doesnt fail to send begin casting packets often, but by the time a begin casting packet is received lac has already done precast, midcast, and changed spell state to the next spell.
This can't be changed either, as precast must be sent prior to the spell begin packet being received. Any change that prevents starting a new spell may also prevent players on retail casting when they know they can, but the client doesn't.

You are the first person to bring this up, so I don't think it is fragile or widespread. FFXI has a max APM of like 15 for casters, there isn't "gas" in the first place. There is a 2.5+ second cooldown from a spell finishing and its effect taking place before you can start the next spell; this is not "quick succession" by any gaming standards. Fat fingering is probably the most viable complaint, but I really don't see a need to save users from themselves in that aspect.

Further, waiting for cast start to handle midcast is also detrimental. The way it is currently set up will correctly get midcast even under chainspell, spontaneity, instant magic proc, and for fast spells like stun and flash with 80% fast cast. Waiting for a cast begin packet would prevent these in almost all cases due to how the client's packet timing is structured.

Finally, client is unaware of fast cast unless provided by the user or calculated from gear/traits/buffs. If secondary casts were blocked starting from the begin cast packet, the block duration would need fast cast to be reasonably accurate and still not account for latency.

Ultimately, I don't see a reason to make things worse for highly knowledgable retail players compensating for server flaws just to help private server players who are worried about fat fingering. There are certainly possible implementations with reduced risk of harm, they could be on a toggle, but there isn't a clean and universal fix without negatives.

I understand the complexity of the issue and lack of a clean solution without side effects. I also respect your choice to not want to change anything. I'll find a work-a-round. Thank you for your response.