* Above calculation has some micro variances to it which were leading to strange behaviour like the bike's tilting not working properly with `cl_syncinput 1`.
* Issue doesn't occur with `cl_syncinput 1` because `processinput()` returns when p->newowner >= 0 before `applylook()` is called from within it.
* Fixes#96.
* Need to add `p->horizAdjust` in with `p->q16horiz` because the values passed to that variable are the same as what would have been directly added to `p->q16horiz` in `processinput()`.
* Leaving mouse input to apply after calculating the pitch lets us take advantage of the calculated pitch's accuracy to provide consistent mouse input across the pitch's range.
* For RR, `processweapon_r()` was performing angle and horizon changes directly which provided a harsh experience with the default `cl_syncinput 0` mode.
* Added `angAdjust` variable to `player_struct` for use with ticrate angle adjustments.
* Renamed `horizAngleAdjust` to `horizAdjust` so that there is less confusion with the new `angAdjust` variable.
* Removed `horizSkew` variable, can just use `horizAdjust` for this.
* Replaced all calls to `addang()` and `addhoriz()` with the appropriate additions/subtractions to `angAdjust` and `horizAdjust` respectively.
* Removed now unused `addang()` and `addhoriz()` setters from `player_struct`.
* Define new function `resetinputhelpers()` to eliminate code duplication between `processinput_d()` and `processinput_r()` functions.
* Remove `p->q16ang` and `p->q16horiz` direct setting from `FinalizeInput()`.
* Change `applylook()` to accept an `fixed_t adjustment` for changing the player's angle. This can either be `input.q16avel` when `cl_syncinput` is 0, or `sync[snum].q16angvel` when `cl_syncinput` is 1.
* Change `sethorizon()` to accept an `fixed_t adjustment` for changing the player's horizon. This can either be `input.q16horz` when `cl_syncinput` is 0, or `sync[snum].q16horz` when `cl_syncinput` is 1.
* Re-work `sethorizon()` to always adjust `p->q16horiz` using the true pitch code. This closer resembles the EDuke32 implementation as per SVN 7342.
* Re-work returning to center to work off the true pitch code and always ensure that the player returns to center.
* Implement work-around for RR where we need to call `sethorizon()` before the call to `fi.doincrements()` like the original game, but also after the call to `processweapon()` to apply any angle or horizon changes due to weapon recoil, etc. We work around this by calling `sethorizon()` from within `doincrements_r()` only if `cl_syncinput` is 1 and only if `doincrements_r()` is to return 1.
* Also changed `gethalflookang()` to camel case `getHalfLookAng()` for easier reading.
* Also broke a very long if statement down into smaller chunks for readability.
* Returns a true double result.
* Also supports fractional input for fractional input. That is, if `sintable[1]` = 50 and `sintable[2]` = 100, `calcSinTableValue(1.5)` = 75.
* Increased precision of `BANG2RAD` define to use double and not float.
* As such, revert addition of `sintablef[]`.
* `displayrooms()` ultimately should be adjusted as well. For now, just relying on integer truncation as this is just a proof of concept.
# Conflicts:
# source/core/gamecontrol.cpp
# source/core/gamecontrol.h
Unfortunately the only thing that can be done here from inside the engine is to increase the likelihood of the animation actually starting.
Ideally the broken script should be replaced but with the way CON replacements are done this is not possible.
