Difference between revisions of "Talk:MoveTo"
Jump to navigation
Jump to search
no edit summary
imported>Reinhartmenken |
imported>Ulto leif |
||
| Line 31: | Line 31: | ||
: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"). | :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. --[[User:JustTim|JustTim]] 05:06, 29 May 2006 (EDT) | :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. --[[User:JustTim|JustTim]] 05:06, 29 May 2006 (EDT) | ||
::A note on that problem--I had noticed that there seems to be a difference between a typical activator .nif and a typical static .nif, as activators seem to move fine with setPos (with the exception of occasionally disappearing when going from cell to cell) but stop working when you change the .nif file to one from a static. | |||
::I messed around with the .nif nodes a bit, and I found I could get a nif file from an underwater rock (i.e. a static) to function properly by replacing its bhkRigidBody node with a bhkRigidBodyT node stolen directly off of an aylied press block, and keeping other parts of the data tree intact. I am, however, still using the modified nif file on an activator object, whether the rock can now be moved properly as a static is unknown. | |||
::Also note: since setPos essentially teleports the object, the object mentioned above doesn't interact properly with other objects while moving, though interaction is certainly there. Objects placed on top will tend to fall off, objects placed in its path may get stuck inside, etc. Expect headaches if you're trying to actually simulate a moving solid object. --[[User:ulto_leif|ulto_leif]] 16:51, 30 June 2008 | |||
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. [[User:Scruggs|Scruggs]] 20:11, 26 June 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. [[User:Scruggs|Scruggs]] 20:11, 26 June 2006 (EDT) | ||