Talk:SetPosition - ObjectReference

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 Papyrus 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 on 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)

The various translate functions are not affected by this bug. --Fg109 16:13, 9 May 2012 (EDT)

I wonder if this displacement is the displacement from where it was when you picked it up, to where it is when you drop it.

I also wonder if this is related to the bug with dynamic clutter and room bounds, where an item knocked or lifted into another room bound becomes invisible; perhaps the "get" coordinates are still returning coordinates within the first room, so the item is not drawn in the second.

I also wonder if this is related to the bug of moving chests - I seem to remember reading somewhere that there was a way to move chests that would make the chest *look* like it was in one place, but it would be usable in another.

I also wonder if this disparity is video memory (handling displaying) vs code memory (handling things like picking up, collision, etc)

I admit these possibilities are very pie-in-the-sky handwavey maybes. --Catwheezle 01:31, 19 May 2012 (EDT)