.getP and .getH are the numbers right?

Scripting Issues
1

Hey, I always noticed this, but never took the time to look at it. When you get a objects P and H and turn them around; their numbers for P and H seem to go on forever… Shouldn’t they end at around the 360 mark or am I really off on how movents work?

For my game, the user atm can still do “flips” with their camers and the numbers can end up becoming very big and sending thos numbers across the network can suck up alot of bandwith. So I’m just checking to see if thats seems right to you.

As for fixing the problem, I haven’t put anything togather yet, but simple dividing the numbers should give me a smaller base number that means the same thing, but not sure if that wise or not, lol.

Also, I like to add I’m having a problem with this bit of code. For some reason its printing off two different base.camera.getZ() after setting the fluzidZ to “test” by moving down one. By this I mean TempZ is pring off -13 while after the fluid move it’s like -0.00002314. I think it has to do with with the frames/moving updates, but wasn’t sure.

          if self.GravityTime <= task.time:
            tempZ = base.camera.getZ()
            base.camera.setFluidZ(render, - (.1 * self.elapsed))
            base.cTrav.traverse(render)
            if tempZ == base.camera.getZ():
              self.FallVelocity = 0
              print "Gravity not at work"
              pass
            else:
              print "Gravity at work"
              self.GravityTime = task.time + .01
              self.tempZ = base.camera.getZ()
              self.FallVelocity = self.FallVelocity + (9.81 * self.elapsed)
              base.camera.setFluidZ(render, - self.FallVelocity)
              base.cTrav.traverse(render)
2

If you’re checking or modifying the angles in a task you could limit them from -360 to 360 with something like this:

if(angle>360):
    angle-=360
if(angle<-360):
    angle+=360

You could cap it at from 0 to 360, or from -180 to 180 if it’s not important to know in what direction a object started to move.

…or you could use quaternion (if you know what they are)

3 
angle = angle % 360

:wink:

% is modulo, aka remainder (ie it divides, then gives you the remainder).
That line should make your rotations keep within reasonable bounds.
And it is perfectly good to limit your rotations in this way, ive never had issues with it :slight_smile:

wezus code works too, i just like modulo.

4

Thanks guys (or gals?) works like a charm. Still not sure why those numbers would increase forever tho.

5

The numbers keep increasing forever because they represent a sort of additive transformation. What I mean to say is, the number doesn’t represent the final rotation, it represents the amount of rotation that has been done to get where it is. Visually, this means that 360 and 3600 look the same to us, but 3600 means that the thing in question has rotated around ten times, rather than just one. If you don’t need that extra information, modulo is the way to go to dump it.

Also, someone correct me if I’m wrong about this, but I’m 99.9% sure that’s how it is.

This can be a big difference in animation, for example. If you wanted to tween a figure rotating 3 full rotations in a modeling/animation package, you’d start with a 0 rotation and end with a 1080 rotation. The computer understands, and will tween 3 full turns in the frames in between.