str8g8 on 6/1/2006 at 20:08
this is a work in progress combination number lock:
Inline Image:
http://img.photobucket.com/albums/v621/str8g8/lock2.jpgI keep track of the values by incrementing a global each time it is frobbed... the problem I am having is with the rotations getting out of sync ... it is almost as if each time it is frobbed it rotates an extra degree, so that after a while the number on the lock does not match the global
Code:
When I am frobbed by player
Set HighlightDist to 0 on linked objects MYSELF
Set physics keyframed state on actor(s) at end of MYSELF to TRUE
Set angular velocity to X=0 Y=36 Z=0 degrees/second on linked object(s) MYSELF
Delay 1 GAME seconds
Set angular velocity to X=0 Y=0 Z=0 degrees/second on linked object(s)
Set HighlightDist to 128 on linked objects MYSELF
Reset script conditions and actions
(The highlight dist changes stop the player frobbing before it has finished rotating.)
Shouldn't the above lead to a precise 36 degree rotation? :confused:
cheers
str8g8
Ziemanskye on 6/1/2006 at 21:20
Does that not like depend on game "ticks" and physics code - I mean maybe it is rotating further because it's the deceleration in havok rather than just stopping, or because it's rotating for an extra 1/5 of a second while it works out what the stop command actually is.
Not that I know how to test or stop such behaviour. :erg:
demagogue on 6/1/2006 at 21:37
Well, since the logic looks good, mathematically speaking the problem has to be either inflated speed or inflated time leaking in if it's getting over-rotated over time. (My intuition would be the latter just because we can *see* the speed clearly.)
But either way, they have the same solution no matter what (if the inflation is mathematically consistent, which you'd think it would be), which is to either slow the rotation speed ever so slightly, like to 35.95, or slow the time down slightly, like to .95 seconds, and then just experiment over something like 100 frobs, tweaking the values, until it looks right on enough for gameplay purposes.
---------------------------------------------
For what it's worth, I'd speculate on where the extra time or speed is coming from ... although it doesn't matter since the solution is the same.
For time, one idea is the old problem that an extra bit of time isn't slipping in between the end of the while/do loop and what happens after its end condition is met ... that is, that a bit of time isn't slipping in between these two lines:
Delay 1 GAME seconds
Set angular velocity to X=0 Y=0 Z=0 degrees/second on linked object(s)
For speed, it could just be an slight discrepency built into the physics or something (Ziemanskye's theory is actually plausible, I didn't think of it). It would be a problem if (as I'm guessing) the 36 degrees/sec rotation is measured from the origin, so if it's even slightly off, since the face of the wheel is a distance out, it inflates that small difference in rotation speed, which over rotations just keeps adding up until it gets pretty big from the perspective of the surface.
But again, the solution would be the same as above.
Other than this, I don't see anything wrong with the coding or logic itself that would be the problem that you could fix any other way.
Komag on 6/1/2006 at 21:43
Or you could do something like reseting the object whenever it gets back to 0 or whatever
jay pettitt on 6/1/2006 at 22:55
Ok, I'm talking out of my arse. But just in case: the difference between 0 and 36 is 37.
str8g8 on 6/1/2006 at 23:00
thanks for the response guys :)
Ziemanskye's theory sounds plausible; if the velocity is zeroed, it might carry on going for a fraction or something. I might also check out the smesh after what demagogue said, possibly the pivot is off centre or something?
Quote:
Or you could do something like reseting the object whenever it gets back to 0 or whatever
That's kind of what I've been trying to do, as I reset the global anyway, but so far I haven't found a way of setting a smeshes rotation absolutely to a specific value, only starting and stopping it.
jay pettitt on 6/1/2006 at 23:17
No really. There are 37 degrees between 0 degrees and 36 degrees.
Code:
Set angular velocity to X=0 Y=35 Z=0 degrees/second on linked object(s) MYSELF
...for the win.
Though I've never scripted T3 and in all probability you've tried already and there may well be other timing factors at play also. But just in case: if you want 36 degrees of spinnyness, that's what you want. Also, I could just be wrong - it's been known.
Krypt on 7/1/2006 at 00:07
If I recall correctly, angular velocity is just the speed it rotates rather than the number of degrees. Your script tells it to move at a speed of 36 for one second then stop. If the scale is degrees per second then it might work. Since it doesn't work, either the scale is different or you have calculated the rotation incorrectly. You'll probably just have to tweak the numbers until you get the desired effect.
There are also other means of achieving the same effect. You could place 10 of each wheel rotated to each number and toggle bOutofWorld through script to determine which number shows. That is pretty messy, though it would allow complete control over it and would guarantee the wheel is always in the position you think it is. You also might be able to make each wheel a door and try messing with the properties on those to have it rotate.
str8g8 on 7/1/2006 at 00:33
Well, the magic number seems to be 35.6 degrees/second ... what this tells us I don't know, and maybe if you frobbed it for long enough it would still go out of sync, but it seems workable.
Quote:
You also might be able to make each wheel a door and try messing with the properties on those to have it rotate.
I tried this at first, but the door controller stuff seemed unsuited in that it only has two states, that is open and closed, whereas this system needs 10 states. Using bOutOfWorld would be completely accurate, but you wouldn't see the rotation, which would be a shame.
What I found strange was not being able to access the object's rotation directly from the script ... even to just reset the rotation to 0 after a cycle, I guess that stuff is just "locked away" within the havok controller.
anyway, thanks for all help!
btw if anyone would like the custom smeshes to play around with let me know :) Perhaps someone could come up with a better system, I'm currently doing it with 10 scripts (!)
