BetterSpades ignores reload stop

[Haxk20]

In AoS reloading works in 3 stages:

1. Client informs server of reload event. This packet can contain weird things. Such as 255 255, 0 0, Or in the case of BetterSpades real player clip and reserve count (Good choice i like that). In this moment server starts reload.
2. Server notifies client that we received the reload event and notify it of reload start and include in the packet exactly what client sent to us in previous packet as the notification of start.
3. Server after the exact time it takes to reload notifies the client of reload finished event and sends client reload packet containing the ammo in clip and reserve count.

OpenSpades and Voxlap (Not better spades) do NOT finish reloading if the third step doesnt happen and just cancel reloading on their side. The sound still plays but actual bullets are not given to the player. OpenSpades and Voxlap actually do not check what server sends in the third step. They just replace player ammo info with that.
BetterSpades is not like this and actually finishes reloading for some reason even tho it is not told to continue and adds the bullets to player.

This cancelation of reloading may happen for multiple reasons. Such as starting to sprint or switching weapons.
This was observed on SpadesX Server which has anti cheat against finishing reloading on weapons that are switched.
OS and Voxlap both behave correctly as they should when not sent the final packet and BetterSpades completely disregards this information and continues regardless.

This has 2 effects:

1. Players actually finish reloading thus having bullets they should not have.
2. Getting completely out of sync with server ammo count.

The first of the effects is easily avoided as any good server should check if player has the ammo to perform action with a gun.

The second one is not so easy. Since OpenSpades and Voxlap do not report back their internal ammo counts to server, no server actually checks this info. We do send to the client our ammo count which server applies.
But this happens in the third and final step of reloading and since we do NOT finish reloading actually the third step doesnt happen thus player can chain these reload skips going more and more and more out of sync with server until it cant no more and we end up in an event where client side may still have some bullets in reserve or clip and server side no longer has any and thus any reload event is disregarded.

In the best case scenario where server has limits it will only affect player where their shots wont actually be registered and they may get mad.

The worst case is when server does NOT have limits and takes every bullet as real at which point we have extra ammo hack. And by chaining them we may end up with up to 10 more bullets.

On scale from 1 to 10 on criticality level i would rate it at a solid 6. Maybe 7. It is a rare event but when it happens in can really screw things up. And when a player is aware of this exploit they can use this on unpatched servers to cause havoc.