Hey there. If you click on this you probably know what this is anyway. Just to demonstrate one particularly useful aspect of the new variable setters, I'll be showing you a basic method to setting up a numerical integration and derivation function. We'll just be using a trapezoidal method and a time-step secant method for each, respectively.
The cool thing about variables is that they just do one "calculation" in each clock cycle. You can figure out how many "clock cycles" a second the game does but just setting up an incrementor locked to a time range, i.e., add a variable timeSteps = timeSteps + 1, with an activator of something like (Time>1)&(Time<2). After 2 seconds have passed in the game, you can simply read off timeSteps to find the number of clock cycles per second in the game. Now that we know this calculation frequency, which is also our max integration or derivation frequency, we can very easily set up the trapezoidal method.
First, let's add a variable valueNow. This should be equal to whatever value you're trying to integrate, for example, GS would be one that would have some good physical meaning. Now, if we add another variable higher in the list order (variables are executed in the order they are at in the setter list) called valueLast equal to valueNow, this allows valueLast to grab the value of valueNow before it is "overwritten" by the current value of the function. Now that we basically have an xi and xf, it's incredibly simple to figure out the trapezoid's area: ((valueNow - valueLast)/2)*(1/Hz), where Hz is the clock cycle frequency we solved for earlier. If you define this expression as a variable, let's say, trapezoid, you can then add another variable named integral that has the value integral + trapezoid such that it will add the current trapezoid's area to itself every cycle. Now you have a complete numerical integration technique for FT.
As for derivation, it is even simpler... Repeat the same process, but instead of trapezoid and integral, simply add a variable derivative such that it is equal to (valueNow - valueLast)/(1/Hz), which is simply the change divided by the unit of time, that is to say, the derivative.
That's all for me today. I've a flight to catch in a few hours!
Ok. So I had the time to actually do the testing, and it appears that clock cycles run at 100Hz for normal speed, 800Hz for slow-mo and 100Hz for fast-forward. However, the timescales of each of these are different, so keep that in mind... slow-mo is the only setting that gets you more clock cycles per game "Time", 8 x the resolution to be exact.
@SnoWFLakE0s
Thanks.
This help clarify a lot of things for me.
@GuyFolk
.
In case you would like to read this article.
@SnoWFLakE0s my clock speeds aren't always perfect, sometimes it misses one
@SnoWFLakE0s Ditto. I did a bit of math on the plane to figure some stuff out, specifically a new way to express lateral/longitudinal/vertical velocities (all of the current expressions seem to break with wind). Got some pretty good progress, so I might make a flight system or something, idk
@spefyjerbf
.
Yeah. The recursion ability is incredibly powerful. I just got out of first semester and in winter break lol.
@V
.
Mobile "low physics" runs 50 Hz.
The VR headsets go from anywhere from about 60 to 120Hz.
Variables can increment like that? Ooh nice. I haven’t had the time to mess with SP in a while, but I may give it a whirl in a week or so
This is cool and all, but wouldn't any amount of lag begin to throw things off? As the clock cycle will probably slow down when things are laggy, compromising time based things.
Also, im pretty sure the game slows down FT calculations in low physics, and maybe on mobile and oculus quest as well
Oculus quest is locked at low physics btw