Difference between revisions of "MoveTo"
Jump to navigation
Jump to search
imported>Haama (Standardized) |
imported>Syscrusher (→Notes: Added code example to workaround a problem with collision meshes when moving statics.) |
||
(7 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
'''Syntax:''' | '''Syntax:''' | ||
MoveTo '' | ''[reference].''MoveTo TargetRef'', x, y, z '' | ||
''[reference].''MoveToMarker TargetRef'', x, y, z '' | |||
Moves the object to the specified target location. | |||
The x, y, z are optional offsets in [[Oblivion Units|units]] from the target reference. | |||
'''Example:''' | '''Example:''' | ||
MoveToMarker HiddenCaveMarker | |||
MoveTo player, 512, 0, 0 | MoveTo player, 512, 0, 0 | ||
==Notes== | ==Notes== | ||
* '''MoveTo''' and '''PositionCell''' perform the same function, but use different parameters ('''PositionCell''' uses coordinates while '''MoveTo''' uses a reference). | |||
* If this function is used to move the player, it will also act as a [[Return]] function -- no following lines of the script will be processed. | * If this function is used to move the player, it will also act as a [[Return]] function -- no following lines of the script will be processed. | ||
:*One way to prevent this is creating a Function with just the MoveTo. the function script will stop after the MoveTo, but the calling script will continue. | |||
::Example: | |||
... | |||
PlayerRef.call MyMoveTo AnvilFocsleMarker | |||
... | |||
---------- | |||
scn MyMoveTo | |||
ref refTarget | |||
begin Function {refTarget} | |||
MoveTo refTarget | |||
end | |||
* This function works as expected for Actors. For most other object types, like containers and activators, the object's coordinates are updated but its world art is not. Additional scripting may be necessary to ensure the object moves properly: | * This function works as expected for Actors. For most other object types, like containers and activators, the object's coordinates are updated but its world art is not. Additional scripting may be necessary to ensure the object moves properly: | ||
<pre>myObject.disable | <pre>myObject.disable | ||
Line 15: | Line 32: | ||
set xp to myObject.getPos x | set xp to myObject.getPos x | ||
myObject.setPos x xp</pre> | myObject.setPos x xp</pre> | ||
* Moving a static object may update its visible position but not its collision mesh location. To work around this, disable and move the object on one frame, then enable it on the next frame. This must be done in the GameMode block: | |||
<pre>if myObject.getDisabled | |||
myObject.enable | |||
endif | |||
; This must be last so the above code is activated *next* frame... | |||
if [some_condition_to_trigger_movement] | |||
myObject.moveTo [location] | |||
myObject.disable | |||
endif</pre> | |||
* In the above example, the condition to trigger movement could be setting a quest variable to 1 in a dialog result or quest stage result, in which case you would then set that variable back to zero as you move the object. | |||
* Note however, that if the moved object is moved to a new cell, it may snap back to its original cell after quit/reload (while keeping the new x,y,z coordinates). This seems to not happen as much when moving between Tamriel subspaces, but definitly happens when moving to and between Shivering Isles and Oblivion worldspaces. If the object being moved is only supposed to be a marker, consider using a marker actor instead. (See [[Teleport Recall]].) (Actors do not suffer from worldspace snapback, and should react correctly to closing of an Oblivion gate.) | * Note however, that if the moved object is moved to a new cell, it may snap back to its original cell after quit/reload (while keeping the new x,y,z coordinates). This seems to not happen as much when moving between Tamriel subspaces, but definitly happens when moving to and between Shivering Isles and Oblivion worldspaces. If the object being moved is only supposed to be a marker, consider using a marker actor instead. (See [[Teleport Recall]].) (Actors do not suffer from worldspace snapback, and should react correctly to closing of an Oblivion gate.) | ||
* To adjust the object relative to the players heading (i.e. place it in front of the player), you'll need to offset it's position. See [[Summon Object]] for full code sample. | * To adjust the object relative to the players heading (i.e. place it in front of the player), you'll need to offset it's position. See [[Summon Object]] for full code sample. | ||
* Script functions that make one actor target another (like [[SayTo]] or [[StartCombat]]) will not work when MoveTo is used on the target in the same frame, even when the target is moved only by a few inches. | * Script functions that make one actor target another (like [[SayTo]] or [[StartCombat]]) will not work when MoveTo is used on the target in the same frame, even when the target is moved only by a few inches. | ||
* MoveTo can be very problematic in some situations. See [[Common Bugs#MoveTo Oddities|MoveTo Oddities]]. | |||
==See Also== | ==See Also== |
Latest revision as of 16:35, 29 December 2013
Syntax:
[reference].MoveTo TargetRef, x, y, z [reference].MoveToMarker TargetRef, x, y, z
Moves the object to the specified target location.
The x, y, z are optional offsets in units from the target reference.
Example:
MoveToMarker HiddenCaveMarker MoveTo player, 512, 0, 0
Notes[edit | edit source]
- MoveTo and PositionCell perform the same function, but use different parameters (PositionCell uses coordinates while MoveTo uses a reference).
- If this function is used to move the player, it will also act as a Return function -- no following lines of the script will be processed.
- One way to prevent this is creating a Function with just the MoveTo. the function script will stop after the MoveTo, but the calling script will continue.
- Example:
... PlayerRef.call MyMoveTo AnvilFocsleMarker ... ---------- scn MyMoveTo ref refTarget begin Function {refTarget} MoveTo refTarget end
- This function works as expected for Actors. For most other object types, like containers and activators, the object's coordinates are updated but its world art is not. Additional scripting may be necessary to ensure the object moves properly:
myObject.disable myObject.moveTo [location] myObject.enable set xp to myObject.getPos x myObject.setPos x xp
- Moving a static object may update its visible position but not its collision mesh location. To work around this, disable and move the object on one frame, then enable it on the next frame. This must be done in the GameMode block:
if myObject.getDisabled myObject.enable endif ; This must be last so the above code is activated *next* frame... if [some_condition_to_trigger_movement] myObject.moveTo [location] myObject.disable endif
- In the above example, the condition to trigger movement could be setting a quest variable to 1 in a dialog result or quest stage result, in which case you would then set that variable back to zero as you move the object.
- Note however, that if the moved object is moved to a new cell, it may snap back to its original cell after quit/reload (while keeping the new x,y,z coordinates). This seems to not happen as much when moving between Tamriel subspaces, but definitly happens when moving to and between Shivering Isles and Oblivion worldspaces. If the object being moved is only supposed to be a marker, consider using a marker actor instead. (See Teleport Recall.) (Actors do not suffer from worldspace snapback, and should react correctly to closing of an Oblivion gate.)
- To adjust the object relative to the players heading (i.e. place it in front of the player), you'll need to offset it's position. See Summon Object for full code sample.
- Script functions that make one actor target another (like SayTo or StartCombat) will not work when MoveTo is used on the target in the same frame, even when the target is moved only by a few inches.
- MoveTo can be very problematic in some situations. See MoveTo Oddities.
See Also[edit | edit source]