Talk:MoveTo

Restrictions?

Does anyone know of any restrictions on this command? I and another person can't get MoveTo to move objects, but it seems that activators move sucessfully using the exact same code. Update: An activator with a model set doesn't seem to move with this command. (I used skull01.nif) Mrflippy 00:42, 8 April 2006 (EDT)

Hmm... Moveto doesn't seem to like xmarkers (reference.moveto player doesn't work). Any suggestions?Talkie Toaster 12:26, 20 April 2006 (EDT)

What does this function work on? I think testing needs to be done on this. The article says it works for Actors, and implies that it doesn't work for some (or all) non-actors. Flippy is saying that it works for Activators with no mesh, but not for non-activators or activators with a mesh. I personally would really like to use this function for a neat effect I have in mind, but it won't work if I can't move meshes with this... I may do some testing later, if I get the chance, but testing definitely needs to be done by someone, regardless. --DragoonWraith 16:57, 23 May 2006 (EDT)

from my testing it seems to work fine on misc items. i created a test Mark/Recall spell, with the mark spell simply calling markObj.moveto player. the misc item in this case was a paintbrush. seemed to work repeatedly. :shrug: Scruggs 22:54, 26 May 2006 (EDT)

Well, that's encouraging. Thank you! --DragoonWraith 22:56, 26 May 2006 (EDT)

It works fine on any item, even those created with placeatme, but only as long as they're in a loaded cell. That's not really a moveto problem, it's a general problem with non-persistent references. Moveto on a carriable item once it is in a container/inventory is a very reliable way to crash the game, no matter if the reference is persistent or not.--JOG 03:28, 27 May 2006 (EDT)

Understood. In my case the object was previously placed in the editor, persistent, and disabled...so that ensures that moveTo will always work, correct? Scruggs 11:49, 27 May 2006 (EDT)

Say I have an object set to constantly MoveTo player 0 0 0, will that follow him through a loaddoor? If this script is in a Quest script (objectID.MoveTo player 0 0 0), and the player goes through a loaddoor, will that crash or will that work? If I have a reference variable instead of the actual ID, will that change anything? If that reference var references an object created through PlaceAtMe, does that change anything? If it works as it all, must it be a persistant reference in order to do so? --DragoonWraith 13:44, 27 May 2006 (EDT)

Yes, this should work. MoveTo even moves the object into diffrent cells if necessary. It shouldn't crash the game when you take care that the used reference didn't get unloaded. you should therefore use persistant references. And you don't even need the "0 0 0" thing, just using "MoveTo Player" should do the job. --JustTim 16:50, 27 May 2006 (EDT)

Excellent, thank you. --DragoonWraith 17:13, 27 May 2006 (EDT)

I'm having no luck with activators. "Unexpected behavior" certainly sums it up. Activators don't seem to respond to moveTo in the console, regardless of persistence. In a script, they seem to respond once, with subsequent calls having no effect. Strangely, calling activator.moveTo from a different cell correctly moves it the first time, but after leaving and immediately re-entering the cell, the activator has vanished, and attempts to reference it via the console to check getDistance report an invalid reference! Scruggs 00:02, 29 May 2006 (EDT)

Yes, the behavior of this function on non-actors is a little weird. The best method seems to be a combination of MoveTo and SetPos. MoveTo ONLY works when the object moves into another cell and SetPos does NOT work if the object moves into another cell. Just call both functions and it should work. But you should call MoveTo last, since it might abort the script (like a "return").

But there is a downside: The object loses its special behavior when moved by a setpos function. You can't activate it anymore and collusion doesn't work anymore. --JustTim 05:06, 29 May 2006 (EDT)

After messing around with this function a bit, I'm finding that when called on an activator, it seems to update the activator's position without remembering to update the world art at the same time. Sometimes the object will remain in the same place after a MoveTo, but getPos returns its coordinates as having changed to the new position. So, after calling moveTo, if you call 'setPos x (getPos x)', it seems to force the world art to update. Haven't noticed any issues with collision or activation when using this workaround. Scruggs 20:11, 26 June 2006 (EDT)

So basically, you can keep something always several paces in front or behind the player by executing this command in GameMode followed by SetPos? Sounds a whole lot easier than calculating the heading of the player using trig. --Omzy 22:46, 26 June 2006 (EDT)

Not quite. MoveTo isn't relational in the way PlaceAtMe is. The offset values allow you to offset the position on each axis, but to specify "in front" or "behind" you would still need to take the player's facing angle into account. Scruggs 00:15, 27 June 2006 (EDT)

Bummer, thought it came with directional flags like placeatme. Shows how much use its been to me. --Omzy 00:34, 27 June 2006 (EDT)

Are there any functions similar to GetPos in Morrowind? That could be useful for finding the position, then using the GetAngle (I think) on the player to determine where to put the object. So if angle == 180, then position the object -100 of the player, using the GetPos as a reference (ex player at 2048 -> angle == 180 Move to (X - 128),(Y -0 )) or something like that. The Imperial Dragon 00:44, 27 June 2006 (EDT)