Second try after the revert in 8a28339 due to an unexpected regression.
- Rigidly animated models (e.g. the glTF frog node) were not working correctly,
since cloning the mesh ignored the transformation matrices.
Note that scaling the mesh needs to occur *after* transforming the vertices.
- Visual scale did not apply to skinned models,
as resetting the animation overwrote scaled vertex data with static positions & normals.
For backwards compatibility, we now apply a 10x scale to static, non-glTF models.
We now do scale static meshes, as the bug that caused meshes not to be scaled was limited to skeletally animated meshes,
hence we ought not to reproduce it for skinned meshes that do not take advantage of skeletal animations (e.g. current MTG doors).
However, glTF models (e.g. Wuzzy's eyeballs) up until recently were always affected due to technical reasons
(using skeletal animation for rigid animation).
Thus, to preserve behavior, we:
1. Do not apply 10x scale to glTF models.
2. Apply 10x scale to obj models.
3. Apply 10x scale to static x or b3d models, but not to animated ones.
See also: #16141
The error was caused by fd857374, where 'MenuQuit' was processed after 'try_quit'.
This commit fixes the error by moving the special 'MenuQuit' handling to Lua.
This feature needs a proper API integration to result in a correct
in-game appearance. See #15898 for details.
This is a band-aid solution for the 5.12.0 release.
It literally breaks torches and doors in MTG.
Regardless of whether this is an oversight or not let's not pull this in so close to release.
This reverts commit 612db5b2ca.
- Rigidly animated models (e.g. the gltf frog node) were not working correctly,
since cloning the mesh ignored the transformation matrices.
Note that scaling the mesh needs to occur *after* transforming the vertices.
- Visual scale did not apply to skinned models,
as resetting the animation overwrote scaled vertex data with static positions & normals.
For backwards compatibility, we only apply a 10x scale to static (.obj) models.
The server already includes such check. There must be a desync issue that causes
an ID mismatch, resulting in client crashes. Any such crash must be prevented.
