Talk:TranslateTo - ObjectReference

Hi, I used TranslateTo to move object just in one direction (Y) upon clicking a button (ImperialButton01 - I think It's called). Everything works just fine, the object moves "forwards" but it's collision information, or whatever it's called, does not. I'm still able to walk through the object, shoot arrows through it just like it's not there (on the new place) but I can see it. If I try to walk on it's original position I can't just like it's still there, arrows keep hitting the empty (original object's position) space.

script is pretty simple

just two properties one with moving object one with button

when activated TranslateTo with parameters (position and speed)

end

Activating object is the button set as moving object's activation parent

Is there something else I have to do to make the translation process "real"?

What is the object that you are trying to move? --Fg109 10:24, 12 April 2012 (EDT)

It's an ArcheryTarget - could it be because it's supposed to be static object?-- Umprie

Yes, that's probably why. If you want the collision to update properly, you would need to edit the nif file containing the model and change the value for the BSX flags. --Fg109 16:17, 12 April 2012 (EDT)

I haven't experienced this for myself, but some of my users report back that collision box weirdness resulting from moving statics with TranslateTo is temporary and resolved on cell load. So exit cell, then ~pcb should fix it; or even just save, quit, reload game. --Jaxonz (talk) 2015-02-03T11:39:55 (EST)

To get Static object collisions to work with TranslateTo (to avoid leaving them behind as you describe), you must edit the bhkRigidBody settings in NifSkope to change:

Layer: Change OL_STATIC to OL_ANIM_STATIC.

Layer Copy: Change OL_STATIC to OL_ANIM_STATIC.

Motion System: Change MO_SYS_BOX_STABILIZED to MO_SYS_BOX.

Also, the static itself must be re-created under MovableStatic in the CK, not the regular Static section. --Phinix 05:01, 16 June 2012 (EDT)

For a couple of months, I have been trying to discover a less painful way to have collision intact for actors when using TranslateTo. There's been a tiny bit of success. I've mananged to have collision information return to the player and any actor when translation is complete(not to be confused with the Event of the same name). The downside is, collision is still lost during translation - you/actors will still go through any object while in transit. You may ask what's the difference? Well, if you use the player or an actor with translateto, normally collision does not return even when the translation is complete.

The method of discovery was a activemagic effect script. A very simple script.

Scriptname PlayerTranslationScript extends ActiveMagicEffect

Actor property PlayerRef auto

Float property fSpeed = 0.0 auto
{The speed of translation.}


Float PosX
Float PosY
Float PosZ
Actor CasterActor
Actor TargetActor

Event OnEffectStart(Actor akTarget, Actor akCaster)
fSpeed = 1500.0
	TargetActor = akTarget
	CasterActor = akCaster

	PosX = TargetActor.GetPositionX()
	PosY = TargetActor.GetPositionY()
	PosZ = TargetActor.GetPositionZ()

if CasterActor == PlayerRef
	CasterActor.TranslateTo(PosX, PosY, PosZ, 0.0, 0.0, 0.0, fSpeed, 0.0)
endif
EndEvent

This is interchangable. CasterActor can be replaced with TargetActor(as well as for the GetPos functions). You'll slam into the target, but you'll notice collision has returned. Why this works, I cannot explain, it may involve some internal mechanics I'm not familiar with. This was tested in an exterior, though it should in theory work in interiors but the problem with collision lost during translation will be a lot more noticable. I think this is about as close as I will get to solving this mystery. Oh and this method should work outside of a magic effect script. Will not work with TranslateToRef. Untested with the other flavors of translation functions. Terra Nova2 (talk) 2014-03-19T11:12:40 (EDT)

Global and Object-Relative Angles

The description of the TranslateTo function states that afAngleX, afAngleY, and afAngleZ are absolute world rotations.

Experimentally, it has been determined that only afAngleX is absolute world rotations, whereas afAngleY and afAngleZ are relative to the object being positioned.

As an example, suppose you are manipulating a bucket object which has the Z-axis extending up through it's center:

objBucket.TranslateTo(objBucket.X, objBucket.Y, objBucket.Z, objBucket.GetAngleX(), objBucket.GetAngleY, objBucket.GetAngleZ + 90.0, 1.0, 1.0)

Will cause the bucket to rotate about its own Z axis, regardless of the value of the other angles.

afAngleY is likewise relative to the object itself, however afAngleX does use world absolute angles. It is uncertain why this inconsistency exists. --Jaxonz (talk) 2015-02-03T11:39:55 (EST)

My tests indicate that TranslateTo's angle parameters function exactly as they should. Skyrim uses extrinsic (world-relative) ZYX rotations. Objects always rotate around the world's axes, not their own axes. DavidJCobb (talk) 2015-02-02T20:54:21 (EST)