Difference between revisions of "Talk:SetPosition - ObjectReference"
imported>Fg109 (dropped objects bug) |
imported>Fg109 |
||
Line 19: | Line 19: | ||
we will find that the torch has moved (1.218338, -20.904724, 1.214581) units from itself. | we will find that the torch has moved (1.218338, -20.904724, 1.214581) units from itself. | ||
--[[User:Fg109|Fg109]] 10:57, 2 May 2012 (EDT) |
Revision as of 09:57, 2 May 2012
Dropped Objects
NOTE: My explanation is pure guesswork in order to explain results of my testing.
We know that every object has its own local origin. When the engine renders an object, the model is rendered at the object's origin. When we move an object using the various functions that change position and rotation, we are updating the coordinates of its local origin.
However, there is a discrepancy with objects that are dropped manually (ie not from using the DropObject function) from inventory. A second local origin is created and this second origin is what is used instead when the SetPosition, SetAngle, and MoveTo functions (and possibly the various Translate functions as well) are called on the object. However, the various get position functions and the X, Y, Z object reference properties return values from the object's first local origin.
For example, a torch's second local origin is offset from its first local origin by:
(1.218338, -20.904724, 1.214581)
This means if we use
TorchRef.SetPosition(0, 0, 0)
then we get the values (1.218338, -20.904724, 1.214581) when we call the get position functions from it. Similarly, if we use
TorchRef.MoveTo(TorchRef)
we will find that the torch has moved (1.218338, -20.904724, 1.214581) units from itself. --Fg109 10:57, 2 May 2012 (EDT)