This is needed for implementing reliable serialization of custom translations. As long as they are merely ints they cannot be restored on loading a savegame because the serialization code does not know that these variables are special.
Examples:
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c: In function ‘c_exp’:
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:171:48: warning: declaration of built-in function ‘floor’ without a prototype; expected ‘double(double)’ [-Wbuiltin-declaration-mismatch]
171 | double polevl(double, void *, int), floor(), ldexp();
| ^~~~~
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:171:57: warning: declaration of built-in function ‘ldexp’ without a prototype; expected ‘double(double, int)’ [-Wbuiltin-declaration-mismatch]
171 | double polevl(double, void *, int), floor(), ldexp();
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:200:16: warning: passing arguments to 'polevl' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
px = x * polevl( xx, P, 2 );
^
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:201:17: warning: passing arguments to 'polevl' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
x = px/( polevl( xx, Q, 3 ) - px );
^
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:167:8: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
double c_exp(x)
^
3 warnings generated.
* Change it to a DRotator as that's what the game is expecting. Too many narrowings against DAngle objects needed.
* Utilise object methods where possible.
* Do all math against the object where possible, not its members.
* Change it to a DVector3 as that's what the game is expecting. Too many narrowings against DAngle objects needed.
* Utilise object methods where possible.
* Do all math against the object where possible, not its members.
* This narrowing constructor was causing a problem with a `clamp()` overload in the next commit.
* Believe this is a product of a by-gone time before we had the `XY()` method on `TVector3<T>` objects.
The assumption was made that every object in the ToDestroy list wasn't destroyed yet.
This assumption is wrong in case one object destroys an owned one on its own destruction.
Instead this case must be properly dealt with and duplicate destruction be avoided.
This happened with the panel sprite sentinel in SW's player object.
