 |
The cause of this issue goes back to a fix of mine 2007 - after looking at this again I think I know now how to fix it for good. |
|
|
Fixed in dcc30c473d00bd39471e5b0e0d8f6f06c8222c15 |
 |
The first prefab I tried rotating with the new build was containers/chest_wood_old.pfb. The atdm:target_set_frobable inside the chest, while rotating properly, sent its origin way far away. |
|
|
In fact, the example I gave in "Steps to Reproduce" doesn't work. The origins of the two func_static brushes get sent very far away. |
|
|
I can see the difference - it happens when using the z-axis rotation commands (90 degrees) in the toolbar. It's working when I'm using the mouse-based rotator controls (select and hit R). I have to check why the commands work differently, but at least I can reproduce it. |
|
|
Fixed. The code was using an "optimised" execution path for 90-degree-rotations about the major axes, but the hardcoded Quaternions were wrong for the negative-90-degree rotations (which were used by the toolbar buttons). It was going back to the code initially forked from GtkRadiant, and I'm stumped that it went unnoticed for such a long time. The problem only ever became apparent now that we have proper pivoted rotation handling, where these wrong cos(phi/2) were sending the func_static origins off limit. A nice example of premature optimisation. Nobody would notice the difference in execution speed when using this shortcut over calculating the quaternion from the matrix (the code is all there), but hell, we need to optimise what we can, don't we? Well, yes, you can optimise, but at least do it right. |
|
|
Heh. Thanks for flushing this nasty bit from the code. |
|
|
tested |
- Anonymous
