Hi,
I have made a nice little demo, you will immediately see what is going wrong. Press up and down to let it rotate.

http://www.file-upload.net/download-1563899/rotspeed.rar.html

The most of the time the value of the speed is correct but its "fluttering" around. Try to press up or down for a bit longer.
It goes up to 4,5 (on my pc) and then I have the impression its switching for a few millisecs to other values like 2 or 3. That's wrong and deadly for my project ^^
And the sign (it should be the direction of the rotational speed) of the speed is pretty much random.

Keep in mind that without physics the speed has always exactly the right value.
(You can also find this (unresolved) problem here http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=257365&page=1 and here http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=258399#Post258399)

So, I can't explain this issue better then this, help would be great.

If I understand you right, your question was if the duration of a frame is different when running physics functions. Of course it is, and also depends on other engine functions, on your hardware and many other factors. Frame time can be totally different from one second to the other.

Ok, know its clear why the calculation returns these weird values. But how i can compensate this time changes ?
Here's the calculation:

This first wait(1) is the responsible code line I guess. I need a always constant thing in this wait. Maybe something with time_step ?

You must always divide by time_frame when you want to get a speed.

Speed == distance over time.

So JCL, are you saying the below change would (in theory) solve this calculation?
Or at least "smooth out" the roughness of Rot_Speed caused by physics frame-rate variations.

Nope. It all depends on what you want to calculate. If you want a speed, you need to take a distance and divide it by the time, because that's how the word "speed" is defined:

vec_scale(Rot_Speed,1/time_frame);

But if you don't want an angle speed but just the angle difference between frames, the original calculation was fine. I don't know what he really needed, but assume it was indeed a speed.

What he is trying to get is a "change of angle" in "degrees per second".
(or at least a "degrees per 3DGS-constant-time-related-number".

So he/we are after an angular equivalent of speed. So if (pseudocode)
SPEED.X(quants/sec) = (Start.X - Finish.X) * (1/time_frame)
we want to find
ANGULAR_SPEED.pan(quants/sec) = (Start.pan - /Finish.pan) * (1/time_frame)(?)
where "physics" (and its variable frame rates) happens between "Start" and "Finish".
Wouldnt using time_step give smoother results?
I still have difficulties with time_step, time_fame, & time_smooth.

Thats what I understand theDust to want.

Yes, my previous code was in error, it should have been vec_scale(Rot_Speed, (1/time_frame));

You know better then me what I want now

Ok,
vec_scale(Rot_Speed, (1/time_frame));
seems to improve the calculation, its more stable.
BUT the sign of the speed (very very very important) is switching all the time.
And its switching in a linear way. When the object is turning slow its switching slow and when its fast its switching fast. The sign should be the direction of the speed

You can try it out with my demo above.

Thats because when you f.i. add 10 to an angle of 355, the result is 5 degrees.

But without physics the direction of the speed gets calculated correctly. Actually we worked this angle-problem out (or not ?):

(Quote EvilSOB http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=257365&page=2)
vec_diff ignores the switching between 0...360 or -180...180 of the angles, when these values are being stored in a manually created VECTOR, they wont be treated as angles, and therefore wont suffer the +180, -180 clipping.

Maybe that's not he whole story ?