Currently, BetterCombat completely ignores (or overwrites?) the attributes player.swinging and player.attackAnim, which the vanilla game sets whenever the player attacks. This means that any other mod that bases some functionality on the player attacking and checks one of these two attributes to see if an attack is ongoing, becomes incompatible.

To give some context, I'm the developer of Shield Expansion and I have a feature that let's players attack straight out of blocking without having to let go of right-click first, this enables reacting more dynamically in combat by essentially removing the few ticks the game normally needs to remove the blocking state from the player after they stop using a shield.
So far, I've used both player.swinging and player.attackAnim to check whether an attack is ongoing to disable shield functionality, which works perfectly for vanilla attacks, but has major issues when paired with BetterCombat. And unless I've missed some other way of checking for an ongoing attack, I am unable to fix this on my side.

So essentially, my feature request is for BetterCombat to set the player.swinging state or the player.attackAnim duration while the player attacks, so mods that check for ongoing attacks using the vanilla attributes don't become incompatible. Should there be some other way to solve this that is already viable, then please let me know! :)

Hello!
Thank you for the report, I will investigate as soon as I have time for it. :)

player.swinging and player.attackAnim will not be used by Better Combat, because they are causing side effects in the animations. Rewriting these fields to control Better Combat mechanics is out of question due to the complexity.

But I believe there are alternatives to solve this.

As far as I understand the problem you are trying to detect if a weapon swing is ongoing on the client side. Is that correct?

I need it on the server side actually, that's the problem. Basically I modified the shield blocking state to allow players to attack despite currently blocking, but as Forge doesn't have events that fire when starting an attack, I currently utilize player.attackAnim to check if the player is attacking while simultaneously being in the blocking state, to cancel that state if that's the case.

I can utilize network packets instead, but my tests showed that that is less responsive which is why I was hoping for Better Combat to implement the vanilla fields. But I'll make do with that.

Thanks for looking into this though!

That sounds like a good compromise, I can definitely use that! Thank you very much.

My first idea to solve the problem is the following.
Better Combat API package allows checking if a weapon swing is in progress. This client-side state can be used to check if a player is blocking, and disable the blocking state by sending a packet.
Depending on where you hook this check into, you can send the packet on the same tick or the next one.

Since Better Combat has a windup attack mechanic it will take several ticks for the attack to be manifested in an actual hit.

Unfortunately the API I mentioned isn't as intuitive as I thought.

First cast MinecraftClient to my extended interface.
var client = ((MinecraftClient_BetterCombat)MinecraftClient.getInstance())

To decide if a weapon swing is in progress you can to the following
client.getUpswingTicks() > 0 or client.getSwingProgress() < 1F

This isn't as intuitive as I would like, in the next minor release I will add a convenience function to determine this.
boolean isWeaponSwingInProgress()

API extended in v1.6.0.
Please let me know if you need additional help!