Talk:SetMotionType - ObjectReference

aiMotionType

Only 2 values for this have a description, yet 7 are available. I've marked this page as incomplete for now just because I've added the 5 options that weren't previously listed here but they don't have descriptions yet.

-- Cipscis (talk) 18:22, 20 September 2012 (EDT)

From NifSkope's tooltips on the subject.

1. MO_SYS_INVALID: Invalid
2. MO_SYS_DYNAMIC: A fully-simulated, movable rigid body. At construction time, the engine checks the input inertia and selects MO_SYS_SPHERE_INERTIA or MO_SYS_BOX_INERTIA as appropriate.
3. MO_SYS_SPHERE: Simulation is performed using a sphere inertia tensor.
4. MO_SYS_SPHERE_INERTIA: This is the same as MO_SYS_SPHERE_INERTIA [sic], except that simulation of the rigid body is "softened".
5. MO_SYS_BOX: Simulation is performed using a box inertia tensor.
6. MO_SYS_BOX_STABILIZED: This is the same as MO_SYS_BOX_INERTIA [sic], except that simulation of the rigid body is "softened".
7. MO_SYS_KEYFRAMED: Simulation is not performed as a normal rigid body. The keyframed rigid body has an infinite mass when viewed by the rest of the system. (used for creatures)
8. MO_SYS_FIXED: This motion type is used for the static elements of a game scene, e.g. the landscape. Faster than MO_SYS_KEYFRAMED at velocity 0. (used for weapons)
9. MO_SYS_THIN_BOX: A box inertia motion which is optimized for thin boxes and has less stability problems
10. MO_SYS_CHARACTER: A specialized motion used for character controllers

As you can see there are 10 total options in Nifskope, and I assume that editing them in Nifskope is functionally the same as the motion systems used by the SetMotionType function. I'm curious, how did you get your list of 7 options, and are the 3 options in Nifskope not valid values for SetMotionType?--Pufthemajicdragon (talk) 2013-07-03T03:40:35 (EDT)

Thanks, this is a very helpful list, and gives a sense of what the different MotionTypes do. I am going to add a few comments to the main page that give a similar description for now, until anyone else wishes to edit or clarify further. The reason the list only includes seven here is because those seven options appear as a list of movement type properties in the core ObjectReference script. A comment on the function there suggests that these seven are the only valid parameters for aeMotionType. Egocarib (talk) 2013-08-27T11:37:12 (EDT)

I think the NifSkope values may be leftovers from Oblivion. I've been trying to build a "GetMotionType" function for an SKSE plug-in, and I've found that in Skyrim, the Papyrus values map one-to-one with what the game engine uses. DavidJCobb (talk) 2016-02-18T17:48:27 (EST)

Some objects may not get along with this function

I have observed that there's a chance of causing a crash if you use SetMotionType(4) on any of the interior doors in SolitudeBluePalace. Other objects may also fail to get along with this function. DavidJCobb (talk) 2015-10-07T19:05:48 (EDT)

The situation you described on the MoveTo page on here, sounds a lot like the behaviour that can happen with any of the Translate functions, and MoveTo/SetPosition can all do the same thing when used on certain references. In this case, The "bounding box"(it's a 3D modeling thing, but let's pretend it's the box you see around a selected object in the render window, and they are somewhat related) of the doors are moved, but not the meshes. So calling GetPosition will return the position of said box, but not the position of the mesh. Am I understanding this right? --Terra Nova2 (talk) 2016-02-14T09:47:44 (EST)

If I'm interpreting your description properly, then you're understanding it right. Kind of a weird description, though.

The reference moves, but its 3D model and collision remain in place, so it appears to have not moved. Or, to put it another way: given a move +X 100, the reference moves +X 100, and its model and collision may be offset by -X 100. This video shows the bug in action, but the title and description are somewhat incorrect. (I initially believed that it was a problem with the "move" function that SKSE makes available to SKSE plug-in authors, rather than a Bethesda-side issue. I also believed it was baked into the save for reasons I don't recall anymore, when it's really a problem with the models in memory.) DavidJCobb (talk) 2016-02-14T15:16:11 (EST)

Yeah sorry, it's weird as I always have a problem conveying my thoughts coherently on the net. That's an unfortunate but interesting discovery, and indeed is similar to what happens with the other move based functions. So using MoveTo on doors, heck not using it on any activators that can animate in someway. --Terra Nova2 (talk) 2016-02-14T19:12:04 (EST)