This is because 'classic' aim mode will reset the view if the mouseaim key is not pressed.
The problem with this is that an empty input packet will trigger a view reset. If the meaning is inverted the default aim mode is free mouse view which doesn't try to alter any view state and is therefore preferable for an empty packet.
Fixes#292
This has a threshold that could lead to different behavior, depending on whether synchronized or unsynchronized input is used, it also used an undefined state of gameclock for its calculations.
By basing this on the levelclock consistency is ensured.
* moved the part that alters the input before queuing it to GetInput
* moved moveloop into the main function
* reshuffled a few things for better grouping by task.
None of this was really working anymore, but will have to be rethought once a network stream exists again.
But even then, this is better sent as a separate command, and in MP only.
Currently the bit fields are still separate and they have to be merged, but for now the added memory does not matter.
Having this structure in the common parts will allow work on consolidating the input code, though.
* Build timer still requires initialisation due to multiple `timerSetCallback()` that still need to work.
# Conflicts:
# source/core/menu/menu.cpp
# source/games/duke/src/game.cpp
This removes most of the InputState class because it is no longer used.
The only remaining places still checking scan codes are the modifiers for sizeup and sizedown.
All the rest was remapped to safer methods. The multiplayer taunts are currently inoperable, they will need support of shift-bindings to get proper support.
Previous attempts at leveraging `applylook()` and `sethorizon()` in different spots had pros and cons, but ultimately changing where these functions were called from was a net negative and had hard to diagnose issues.
Maintaining two types of player input is considerable work. Lessons have been learned and will be beneficial when it comes time to re-doing the other games. Ideas from PR #98 for optimising RRRA vehicle experience while `cl_syncinput 0` is in use have been implemented here.
* 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.
* 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.
* Handle button-mashing to provide a better experience.
* Rename `bike_turn` to `boat_turn`.
* Move application of scale to returning value within `boatApplyTurn()`.
* Use doubled return values like Rednukem (20 -> 40, 10 -> 20, 6 -> 12, 3 -> 6, 2 -> 4, 1 -> 2).
* Return `p->TiltStatus` towards 0 if `p->MotoSpeed` == 0 and `p->NotOnWater`.
* Always test if `p->TiltStatus` < `0.025`.
