Difference between revisions of "Talk:SetPos"
imported>Entim (oops sorry. revering my revert) |
imported>ABO (Added some observations about how havok interacts.) |
||
Line 44: | Line 44: | ||
:I think only the Disable/Enable is necessary in combo with the MoveTo as it may be needed to reset their collison meshes(?) I have had CTD's [for some objects] when I used Enable/Disable in the same frame. If you have such trouble then spilt them so they are called on successive frames. [[User:GuidoBot|GuidoBot]] 22:58, 11 April 2007 (EDT) | :I think only the Disable/Enable is necessary in combo with the MoveTo as it may be needed to reset their collison meshes(?) I have had CTD's [for some objects] when I used Enable/Disable in the same frame. If you have such trouble then spilt them so they are called on successive frames. [[User:GuidoBot|GuidoBot]] 22:58, 11 April 2007 (EDT) | ||
=Havok, setPos, and MoveTo= | |||
I've been doing some experiments and one thing to keep in mind is setPos is ignored by havok... so any velocity the object had before calling setPos will be retained, and havok will apply it's gravity and collision rules at the new position to update that velocity. This means if you do a "levitate" spell that uses setPos to hold the actor up in the air, the actor will accumulate velocity from gravity, so when your spell wears off he will slingshot into the ground. [[User:ABO|ABO]] 22:35, 21 May 2008 (EDT) |
Revision as of 21:35, 21 May 2008
I added some additional information that helped me in the process of scripting my mods.--Omzy 11:50, 13 June 2006 (EDT)
Setting this value via computations does not work. Instead, use GetPos with computations and use the result as a variable for SetPos.
This does not work:
SetPos X (GetPos X + 40)
This works:
short xPos Set xPos to (GetPos X + 40) SetPos X xPos
- What's the point of this info? No Function accepts expressions as parameters.--JOG 12:11, 13 June 2006 (EDT)
- Dragoon Wraith TALK 14:36, 13 June 2006 (EDT): Is that fact anywhere on the Wiki? Because I didn't realize that for a while...
- Well, it's implicit that only those things work that are specified as working, when we find out something that wasn't mentioned before we add it, but there is no point in adding info to random functions that things from other programming languages don't work here. There are no arrays, no sub-procedures, no default values on variable definition, no control structures besides if, and so on...--JOG 15:33, 13 June 2006 (EDT)
If you're having a problem getting light to shed properly after updating its position using SetPos, here is a solution using a combination of MoveTo, SetPos, a persistent Light Form, and a Dummy Cell:
Begin GameMode PersistentLightReference.PositionCell 0 0 0 0 DummyCell ; Using PositionCell because SetAtStart did not work, ; though using a Marker in conjunction with MoveTo might- didn't test PersistentLightReference.Disable PersistentLightReference.MoveTo Player Set PlayerPosX to Player.GetPos X Set PlayerPosY to Player.GetPos Y Set PlayerPosZ to Player.GetPos Z PersistentLightReference.SetPos X PlayerPosX PersistentLightReference.SetPos Y PlayerPosY PersistentLightReference.SetPos Z PlayerPosZ PersistentLightReference.Enable End
You could conceivably use another MoveTo in conjunction with a Marker instead of PositionCell, but this method is simpler.
This is just the core of the solution, of course. You'll have to declare the Floats PlayerPosX/Y/Z, place a persistent Light, make a Dummy Cell to move to and from, and replace any references or set up any conditionals in the GameMode block that you need for your particular application. For those of you who are still confused, the exact implementation is included in my Wieldable Torches mod.--The Munchkin Lord 23:06, 25 February 2007 (EST)
- I think only the Disable/Enable is necessary in combo with the MoveTo as it may be needed to reset their collison meshes(?) I have had CTD's [for some objects] when I used Enable/Disable in the same frame. If you have such trouble then spilt them so they are called on successive frames. GuidoBot 22:58, 11 April 2007 (EDT)
Havok, setPos, and MoveTo
I've been doing some experiments and one thing to keep in mind is setPos is ignored by havok... so any velocity the object had before calling setPos will be retained, and havok will apply it's gravity and collision rules at the new position to update that velocity. This means if you do a "levitate" spell that uses setPos to hold the actor up in the air, the actor will accumulate velocity from gravity, so when your spell wears off he will slingshot into the ground. ABO 22:35, 21 May 2008 (EDT)