All I’m doing is simply changing the euler angles and all numbers are adding up before the line where I apply the change, but sometimes, well quite frequently actually, the target is overshot… Any good reason for this… The code looks similar to this:
transform.eulerangles = new Vector3 ( transform.eulerangles.x + 90, 0.0f, 0.0f );
It just overshoots by 1 - 5 degrees, but it is enough to mess things up…
are the parent objects have rotation of 0 all the time?
be aware that the overall rotation is sum of all the rotations of the objects and all its parents up to null (the no-parent).
I can assume that you may be rotating the object in local space and then trying to use it’s transform.rotation which is calculated in world space.
please print (transform.rotation) and (transform.localRotation) and see if you get the same results.
OK, I solved the issue… Well, the problem with the eulerAngles proved impossible to fix even when I un-parented the objects and rotated everything separately using eulerAngles there was an error. It seems as though anytime that you feed the number 360 to a eulerAngle float it turns into 1.001791E-05. So, I tried to ensure that when close enough to the target rotation while it was 360, just make that value 0, but this caused other issues because directly changing the eulerAngles seemed to give very strange results, like I would change it to ( 90, 270, 0 ) and it would jump to ( 0, 180, 0 ) for example because I don’t remember the exact change
What I had to do, is change a lot of stuff.
No parenting, although it would probably work fine with the new structure.
No looking for objects based on specific positions because the Vector3 positions of the objects that I was rotating were reading out as way off and my code failed to find them in the way I originally planned for. It was very strange though because the Vector3 xyz positions read out wrong, but the objects were in the correct positions when looking in the game, otherwise there would be noticeable gaps.
I used raycast to find the objects to rotate because of how hard the were to find by their expected positions. I think this new structure in my script is optimized with the ray casting because I have eliminated a lot of the process I needed for finding the correct objects, it was pretty heavy before.
I used RotateAround() for rotation of all objects because it gives good results and thanks Baste because your suggestion for orbiting a point at a constant speed lead me to find this as a viable option.
Thanks Baste and nirharpaz for trying to help. I think, in the end, I would call it a bug…