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)

OnLoad Event Behaviour

I have observed that SetPosition will cause additional OnLoad events to fire. This was discovered by placing an object in the sky, OnLoad would shoot an arrow down from that object, then SetPosition the object randomly, shoot repeat shoot repeat X times. Every time SetPosition was called the OnLoad would happen again, basically cascading forever until the game told me to sod off with something like 4500 suspended stacks and a crash, this of course after quite some time of me staring at the sky wondering why my stuff is never ending and seemingly growing in intensity. Easily work-around-able via sentinels or states, but still a hillarious gotcha. --Darkconsole (talk) 2016-05-29T04:40:03 (EDT)

Maybe I'm wrong, but I think all the movement functions unload the object they are called on. So OnLoad is fired when the object reaches its new position. --Terra Nova2 (talk) 2016-05-29T13:05:02 (EDT)