No problem, I have been helped alot these past years in the forum and always try to give something back whenever I can (at least for issues I think I have the necessary knowledge and feel comfortable/confident giving advice with).

Your new code seems very solid in general. But there is only one part that concerns me (having the time_step variable modified by a minv() function). By putting your time_step inside minv() you make the code ignore framerate in some cases (in my opinion the wrong cases), which could lead to problems due to low frames per second because time_step=16/(average_fps);
I understand placing time_step inside a "maxv(x*time_step,0.001);" instruction because of dangerously high fps, but I don't recommend time_step inside a minv() instruction.

Explanation:
Early-on when I started to use 3DGS I had some problems with time_step. I started making simple games for my friends (flavored with in-group humor about our own lives, but very dumbed-down due to maximum 2-4 weeks of devolpment).
Since they were aimed at friends and their varied system configurations, (fortunately?) I soon was forced into learning to use time_step prematurely.
But unfortunately, simple games = potencially extremely high frame rates for any high-end systems, and with higher fps rates you get lower time_step values. This was a problem because the most commonly used Lite-C in-built variables use a "fixed" data-format, which have a default weakness...
Lite-C's commonly-used data-type "var" are "fixed" and they only have a precision of 0.001 due to their 3 decimal limitation.
Even when using alternative methods (like the "round()" funcion that gave me an extra 0.0005 precision), whenever a player (or the camera) had a movement or rotation lower than 0,001 (per frame) due to using time_step... the player (or camera) would not move at all because a "fixed/var" would consider it as "zero" (result<0.0004999... = 0.000)!

Basic "work-around" and reasons:
After many problems, I started to use something like "maxv(((bla+bla-bla)*time_step),0.001);" to make sure that high frame rates would never produce results that end up in "rounding to" 0.000... Until you are comfortable with using "frame rate independant" programming I recommend you take this simplified aproach whenever using time_step (and even after growing accustomed to fps-independant programming this can still remain a totally viable option).

Why your "minv()" function concerns me:
For the reasons stated in the above sections I have sometimes felt the need to use "maxv(x*time_step,0.001)" functions as a precaution in cases where there could potencially be extremely high frame-rates (to prevent un-wanted "zero values"), but I have never felt the need to combine time_step with "minv()" when there are low frame rates. There could potencially be high frame rates that produce results below 0.001 causing serious problems (data-precision limitations being rounded mathematically to 0), but low frame rates (below 16 fps) would produce time_step values above "1.0" and that should not be problem.
Remember that extremely high fps can produce low time_step values below 0.001, but extremely low fps produce higher time_step values above 1.001! Withough "maxv()" high frame rates could result in values below "0.000..." making your game "virtually freeze (mathematically)", but low fps only accelerate your game above 1.0 "time_step" values enabeling it to "catch-up" and compensate for the time lost.

Conclusion:
Im my opinion "minv()" is never needed with time_step (to compensate fps differences) because your game movement/rotation will just speed-up the movement-per-frame to compensate the extremely low fps. And limiting the higher time_step values (that low fps produces) in these cases will only prevent the needed (extra) fps compesation, so you would only be causing it to slow down exessively when it shouldn't!
But "maxv(x,0.001)" could be used as a "simple" solution in case the fps are too high, to prevent the game from slowing down too much (under 0.001) to compensate the high fps, because if there are too many frames-per-second the movement each frame would be very little to compensate for so many frames, resulting in it being "rounded to" 0.000 (if it is too small) and "freezing" the game. So for high fps you really would need "maxv()" to avoid your game's values*time_step from "freezing" to zero.

If you didn't understand some of things above, keep in mind that (if I remember correctly) time_step=16/fps;
If necessary re-read the whole post keeping in mind this formulae.

After initially using "maxv(blablabla*time_step,0.001);" with "vars" for some time, I then started to understand the advice I was given from other users on the forum and instead "transformed" all my local variables involved in movement and rotation to more precice data-types like float. Understanding how time_step works and combinig it's results with these (more precise) variables enabled me to have more "acurate" and less noticeable "jumpy-effects" in my rotations and movements.
And when you are more confident with using the basic "maxv() and time_step combination" I recommend you substitute them with "time_frame and max_fps" and read further into the manuall about these and other related functions/variables like time_smooth and time_factor to fully understand how all these crazy "fps-independant" things work together and what is the best combination for your specific needs.


I know this is a long read, but a similar post helped me feel comfortable with all these things