Without this commit, the SMG's ejecting brass tends to fall unnaturally:
If the gun hasn't moved, each casing falls in the exact same trajectory
and in the exact same location.
This commit adds a small amount of random variation to each casing's
veloctiy, which looks more natural.
This velocity estimation routine has been present since the beginning of
time, but it seems that this actually does more harm than good.
Neither the vanilla client nor BetterSpades implements velocity
estimation.
When a player releases the "crouch" key, `Player::TryUncrouch` is
responsible for checking if uncrouching is possible and adjusting the
local player position accordingly so that the legs won't be embedded in
a ground thereafter. There are two cases in which uncrouching succeeds.
Case 1: The player is airborne, and there's room under the legs. Case 2:
There's room over the head.
The old code did not rely on `Player::TryUncrouch` for player position
readjustment. Instead, `Player::SetInput` was actually responsible for
this. Unfortunately, it did not distinguish the cases correctly. It did
check correctly whether uncrouching is possible. However, to determine
which of Case 1 and Case 2 is applicable, it only checked the player's
airborne-ness, therefore it incorrectly selected Case 1 if the player is
airborne but there's no room under the legs. This incorrect
implementation resulted in annoying bugs where a player gets stuck in a
ground if the player uncrouches just above it.
Currently OpenSpades doesnt send the extended version info which contains
some useful info to the server even when being told that it wants it.
This commit adds sending of the packet so servers will receive such info when
they ask for it.
Improves the smoothness of non-local player movement in a server that
sends ten WorldUpdate packages for each second (i.e., 10 updates per
second).
I wouldn't dare to relax the bound further since this technique is
extremely susceptible to jitter. The server sending WorldUpdate packets
with `PACKET_FLAG_UNSEQUENCED` isn't exactly helping since that
introduces discontinuity into the received position stream, and the
denominator lower bound is the only thing that keeps the estimation from
exploding. (The packets should really be unreliable + sequenced.)
This commit completely disables any sign of recoil if
the packet is coming from a player that is not local
player.
We want to apply recoil to local player weapon
but we do not want to apply it to others as
we just want to display what was given to us
(Their client already adds recoil. If not they
are cheating)
`std::nan` converts a given string to a quiet NaN value in an
implementation-defined way. It accepts an empty string, but that doesn't
mean you can pass `nullptr`. Passing `nullptr` causes a segmentation
fault on Linux but does not on macOS, which I think is why I missed that
in the first place.
Actually, `std::nan` isn't even really needed here, hence I replaced it
with `NAN`.
This problem was originally reported in:
<https://github.com/piqueserver/piqueserver/issues/586>
Upon receiving `IntelCapture` with `winning = 1`, the voxlap client
resets both team scores and the holding status of both teams' intels,
but OpenSpades didn't do that, resulting in a weird behavior described
in piqueserver/piqueserver#586. This commit changes OpenSpades' behavior
to be congruent with the voxlap client's behavior.
Fixes#890.
Profiling indicated that a little time (< 10% of `ApplyBlockActions`'s
total execution time) is spent on `Deque` when a large chunk of block
is being removed. Thus even *if* this commit slows down things, the
performance impact would be insignificant.
