Par for course I'd say - instead of checking for replaced player actors at the only time it really matters - i.e. when respawning, it was encoded into the stored value, making the entire thing very messy.
For mow, multiplayer handling is not needed, but when it does, better go over all actors and manually substitute the two relevant fields, i.e. sprite.owner and xsprite.burnsource.
Blood uses the state of the 'run' bit as the sole information that the player is running, which leads to very different behavior with cl_autorun on or off.
Apparently Raze's semantics here do not agree with how it was handled originally and the residual bobbing when coming to a stop was more than a little bit distracting.
This ensures that callback indices are consistent. Runtime registration as performed by NBlood has undefined order and will make savegames non-transferrable.
* Struct made up of binangle class units.
* Create signed clone of binangle for use with look_ang and rotscrnang.
* Append currently outgoing function names with `2` at the end to avoid conflict.
* Started with the most complicated game first.
* Struct made up of fixedhoriz class units.
* Append currently outgoing function names with `2` at the end to avoid conflict.
* Blood had this right. It makes sense that the horizon be based around as it's easier to work with.
* Removed all associated game math to deduct default horizon of 100 when doing weapon zvel etc, meaning actual horizon can just be used.
* Re-did return to center function to work on the already converted pitch. Return speed should be 1:1 with previous code.
* Duke/RR: Fix `SB_CENTERVIEW` not clearing while `cl_syncinput 1`.
* Duke/RR: Remove superfluous call to `apply_seasick()`.
* RR: Change two calls from `playerSetAngle()` to `playerAddAngle()` Updated version of `playerSetAngle()` doesn't stop setting angle until target is reached, a bit too strict for this and compromised vehicle turning.
* `applylook()`: Remove dead flag. Was only used with Duke, no other game called the function when dead anyway. Since the input helpers are processed outside of `applylook()` now this is not needed.
* `applylook()`: Extend function with a bit of commentary.
* For Blood/SW, exposes `SB_LOOK_LEFT`/`SB_LOOK_RIGHT` to games, hooking up `q16look_ang` and `q16rotscrnang` within.
* For SW, use Duke & Blood's return to center function and remove `PF_TURN_180` bit.
* For RR, replace a few misused bits with some bools inside of `player_struct`.
* Since bulk of functionality is sourced from Duke (30Hz), apply proper scaling so SW speed matches (40Hz).
* For Duke/SW, we continually apply `SB_CENTERVIEW` only if it was previously a toggled action, similar to Blood.
* For SW, we remove two SW-specific bits (`PF_LOCK_HORIZ` and `PF_LOOKING`) that are no longer needed.
* For Duke, we remove `return_to_center` and just use the `SB_CENTERVIEW` action bit as required.
* For `sethorizon()`, feature set and adjustment speeds are an averaged out accumulation across Duke/SW:
** GameTicRate is factored in for adjustment decisions to provide consistency for SW being the faster game.
** Adjustment amounts are half way between Duke/SW.
* Doesn't matter for Blood, but will matter for SW in a unified approach. Might as well get it right here.
* Appreciate the literal doubles in lieu of the enums isn't great, but this function will go into the backend in due course.
* Horizon now standardised on 100 like the other games.
* Need to determine where/why/how the player's horizon is starting out at 0 and get it to init at 100 like the other games.
* Looking up/down is a bit rough at first as q16look is disproportionate to where the player is currently looking.
* Won't be an issue with a unified horizon algorithm in the backend.
