Joined: 13 Jan 2006
Posts: 12423 on topic
|Posted: Fri, 4. Dec 09, 15:38 Post subject: [LIB] ms Timer and FPS
|Everyone knows that scripts in TC have no way to measure times < 1 sec.
This script (it's just one file) automatically installs / updates and starts operating immediately.
Your scripts can now
|001 $ms.Timer = get global variable: name='GZ.MST'
(of course, get global var only needs to be done once per script)
017 $Time.ms = $ms.Timer
018 $Time.Carryover = $ms.Timer
019 $FPS = $ms.Timer
contains the regular Playtime expressed in milliseconds - with one catch.
Due to the integer precision it can only display about 23 days of continuous game time.
This fixes the precision issue by counting up whenever $Time.ms is "full".
So whenever $Time.Carryover changes,
$Time.ms is also reset to zero.
I recommend completely resetting your script's internal timing whenever $Time.Carryover changes.
For split-second timing applications it can not possibly matter if there is a little hickup roughly every 23 game days.
Current frames per second.
Note that these are script frames and scripts have a lower priority than graphics.
Script FPS = Graphics FPS in high FPS situations (maybe 35+) but when X3 has to work hard, it's load balancing lets all scripts skip frames to keep the graphics sorta smooth.
When you fire up SETA you may still have 8 graphics FPS but only 1 script FPS.
That is not a problem, though. Since you'll be using this for timing scripts it would be pointless knowing the graphics FPS that have no bearing on the timer that your script is using.
If the library reports 10 FPS then your script is getting a max of 10 FPS.
The first line of the script is a commented out debug flag.
Activate it (and restart the script) and you get a running display of FPS / Playtime as a subtitle.
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.