Please introduce calculus in funky trees.
Yeah crazy, eh?
Now, look, assume SP has calculus, and derivative of function x by function y is de(x, y):
then, Vertical speed indicator input would be: (without the clamp function to prevent the hand to go off limits)
de(Altitude, t)
likewise, the turn coordinator (the turn rate part, not the slip indicator) would be:
de(Heading, t)
Now we don't have those, so they are, respectively:
sin(PitchAngle - -AngleOfAttack * cos(abs(RollAngle))) * GS / 400
and
(sin(Pitch * -100 - AngleOfAttack) * sin(RollAngle) + AngleOfSlip / 18 * cos(RollAngle))
(and the turn rate indicator part is VERY inaccurate, the whole thing is in fact still WIP but I don't think there's much space for improvements)
Seriously, devs, just a simple differential function can make this much difference.
If we have integral, that would be even better, we'll be able to make some crazy instruments.
for example, if integrate function x by function y, with the lower and upper limits a and b is "int(x, y, a, b)"
Then we can make a GPS (actually inertial navigation) with something as simple as:
int(GS * cos(PitchAngle), t, 0, t)
(in other words, the integral of all the horizontal mileage done by the plane since game start)
and nobody would get lost on their way back from the Brown Pearl ever again. (when I tried, my navigation error was so great that I ended up near Snowstone despite I originally departed from Wright Isles)
Really, with the introduction of calculus in funky trees, the range of creativity would be greatly extended.
@AndrewGarrison
@jamesPLANESii Adding AoA in the trig function should account for that.
@SnoWFLakE0s What if you're pitching up but going down? Like when you're behind the power curve doing a STOL landing?
@vcharng Yeah, I interpreted GS wrong. I kept thinking it was the horizontal speed component of the velocity vector. Though this is something else the dev and add to the list of variables we can use
@xiaofootball TAS-GS = wind.
GS actually does NOT take out the vertical part of your speed.
As for whether this is correct, well... I don't think GS would register pitch angle IRL as well.
It would be nice to have calculus functions. But from a coding perspective, it is more efficient to implement more variables for us to use. For example:
.
Vertical Speed (Rate of Climb): simply get the scalar, y-component (I think its y-axis) of the aircraft's velocity vector. This just made me realize... Vertical Speed = TAS - GS
.
Instantaneous Rate of Turn: get the difference between aircraft's current direction and its direction in the previous frame (May need to separate this into both a horizontal and vertical component).
.
Edit: Disregard that whole vertical speed = TAS - GS, I interpreted GS wrong
Angular differentials would be real nice. We already have a way to express vertical speed. I think @SnoWFLakE0s already hinted at it (though I think the trig function should be sine). I have a whole write-up about directional velocities in the description of a recent aircraft upload named “Corpus Ikran”, so feel free to check it out. Might save some time, as you won’t have to derive anything yourself.
Edit: Re-read the post. Looks like you already got those directional velocities. Nice work!
@Avro683Lancaster Yup, I mentioned that in the OP.
After missing the target by about 200 miles north in the return trip from Brown Pearl I think I can definitely use one...
@SnoWFLakE0s Well, yeah, with unnecessarily long expressions.
Another problem for the VSI is that the real word VSIs usually don't have homogeneous dials...
For example, Japanese VSIs in WWII would give the first 90 degrees' rotation to 5000m/ min vertical speed, and the other 90 degrees are 5000- 30000 m/ min...
A benefit to an integral function would be the ability to make an Inertial Navigation System @SnoWFLakE0s
@vcharng
.
My mistake, although the point still stands that most expressions can be done through algebraic means.
@SnoWFLakE0s No it's not.
First, obviously it's not IAS but GS.
and then you have to consider AOA because where your plane is pointing at does not equal to where it's actually going. And AOA's orientation follows the plane, this is where the roll angle comes in because you need to get the vertical part of the vector.
In fact, my function already omitted slip angle, which if not ignored would require us to do the same as we did to AOA all over again.
And finally you need to normalize it into the gauge's dials, which is why you need a constant, that's where the / 400 in OP came in.
All this trouble can be spared as long as they allow us to input a derivative of altitude with regard to time.
Well technically its already there since the beginning as yourself might be finding that you need three or even four digit number to get the exact measurement, such as 0.25:2=0.125, 0.125:2=0.0875
Oh no mathematics has gone to SP...
@vcharng
.
Vertical speed is simply
cos(PitchAngle)*IAS. I don't know why people keep requesting that. Although, the other ones are valid ideas. I will say though, most things can be done via algebraic methods, if you need any calc you do it by hand and input that expression. Calc is only useful if we get specific functions, say the velocity function.@jamesPLANESii more like acceleration XYZ, and two versions, one relative to plane, one relative to map.
And I really hope for some parts-related values like
hp(partID), connection(partAID, partBID)
RPM(engineID) (right now we're using throttle input which isn't accurate, especially for engines with manual propeller pitch)
Plus a total new system, sequence. Useful for fancy landing gears.
I would also like gForceX gForceY and gForceZ too
They’re gonna add it, just in the future