Pitch "jerks"
-
Comparing this to other sims is absolutely pointless - different teams, different sim environment, there are bound to be differences even when we work from the same documentation!
Okay, a quick update for all - I noticed while using the force debugger in the sim that there is a near-constant switching between up and down force on the tailplane. It's in phase with all the videos posted, I think it may be the cause (or at least a part) of the problem. I have been looking at the new CFD entries and the fairly new prop physics. The latter without the former is probably pointless and the former is a WiP, but I thought I'd at least make a start. Curiously, the up/down force is magnified massively and gives a wild swing from about 30 degrees nose up to 30 degrees nose down. Only really starts over 100kts, but then gets very aggressive rather quickly.
It's going to take some time to work this out, I can reproduce it with a warbird at a higher speed (but again, well below that aircraft's max speed) so there is definitely something odd going on.
-
@delta558 Thanks again.
I have not double checked this a 100% but if i am not mistaken, when at rhoughly the same speeds, the Turbo does it more agressive then the Arrow 3Not sure if this shows it okey as YT makes the video a bit slow. They both go to around 140kts IAS
Turbo
https://www.youtube.com/watch?v=GLyvzcX21D4
Regular
https://www.youtube.com/watch?v=wWAs6xsZ8oYBtw something i noticed is that those pitch changes don't really alter the vertical speed a lot. Like sometimes when flying over a mountain the nose may doa single "jerk" up or down like 5-15 degrees and stay there and the VSI needle will hardly move. I learned to just try and ignore the visual pitch change when flying, else i would over correct for nothing.
So it seems to often be mostly a visual thing outside of normal turbulence bumps ofc, those will push the VSI up or down as expected. I will try and make a video of this that hopefully can show this way better then i can explain in text :PThanks again for looking into this, it is highly apreciated.
-
@pdd Read my post just a couple before yours. Here's a link to a video showing the effect in the forces debugger: https://drive.google.com/file/d/1zXAvh6_mAiM3qNuK_stESPIBfOA36uQn/view?usp=sharing
That's gone to Asobo to see if they have any idea what is going on, as there is nothing which I can see that would cause such an effect. Two things to remember: 1) This game's flight model is NOT based in fundamental aerodynamics. It is a mixture of some aerodynamics, some shape-based and some attempts to fix problems caused by the first two. It does not make sense aerodynamically, nor in many respects in terms of geometry. 2) I asked a question directly regarding jet engines back in November on the support forum set up specifically for Devs to get answers to problems. That has still not been answered 6 months later along with several others but it leaves us totally guessing what to do.
When we have to start guessing, you may as well all join in because that's how daft this game's flight model has become - no info, very little support for Devs and it does not make sense on its own. Sorry about that, hopefully we'll hear back from them but until that point we really are stuck with a situation we find unreasonable ourselves.
-
@pdd I have no idea. Getting answers about anything aerodynamic from Asobo is virtually impossible. Very sorry about that, but that's how it has been since the game was released (and bear in mind that the Arrow was one of the first addon aircraft released). The information is just not there, which is probably why several flight dynamics developers of many years standing are no longer developing. We don't like having to guess.
Put it this way, the geometry is correct. We do not have even a basic list of which aerodynamic coefficients are still 'actively having an effect', so they are all filled out with correct figures. It should work. Yet removing one of the coefficients known to no longer be used causes the game to crash. It has to be there, but it apparently doesn't work. It's still filled out correctly, what else is there I can do? They should be able to look at that video and see what is happening with their force debugger - let's just hope that they can work out what the cause is, because I can't and neither can anybody else who has looked at this with me.
Without some decent support from Asobo specifically for Flight Dynamics, we're all guessing.
-
Also worth noting that this doesn't happen with other aircraft I have developed for the sim, so it's not 'the way I develop'. If it was, we'd be seeing it in the other aircraft and might be able to narrow it down. This is PA28-specific.
-
@delta558 said in Pitch "jerks":
Also worth noting that this doesn't happen with other aircraft I have developed for the sim, so it's not 'the way I develop'. If it was, we'd be seeing it in the other aircraft and might be able to narrow it down. This is PA28-specific.
Strange that the fact that it's in the PA-28 but not in other aircraft doesn't help you narrow it down.
-
@sender46 So you'd think, but I have not altered my developing style between the aircraft I have built for this game. Always accurate geometry, then accurate coefficients, then start looking in the game for key characteristics and tweak from there. It's pretty much how I've been doing it for the last 15 or so years through FSX, P3D and even briefly in X-Plane. I have thePA28 accurately defined, as I have the other aircraft accurately defined (as far as this game will allow). Why it is doing what it's doing is, as far as I can see, not a geometry issue, nor is it a coefficients issue.
However, there are many areas of the flight model which (as I have said above) bear no resemblance to either accurate geometry or aerodynamics:
Example 1) Each control surface is defined by its area, its deflection angle and the coefficent of motion which is the effect of its deflection. Simple. This game has added in a 'maxangle scalar' for each one, something which exists nowhere but this game. If the two geometry aspects and coefficient are accurate, why would you need a scalar of any sort? If the effect is too much or not enough, adjustment of the coefficient should suffice. There should be no need for a 'maxangle scalar', so what is it? It has finally been loosely defined in the latest SDK, direct and complete quote:
Scales the deflection angle of the rudder control surface up to the max deflection indicated in rudder_limit and already scaled by the elevator_elasticity_table.
The default value is 1, and if the limit angles are matching the real aircraft, this scalar should be less than 1 as the effective deflection will be aligned with the overall vtail and rudder chord. A value between 0.5 and 0.75 will work with most airplanes.The first sentence, to me, suggests that it is a scalar on a scalar - deflection of the rudder which has already been scaled by 'elasticity' (used since previous versions of FS to control the aerodynamic pressure associated with increased speed, compressability). So why the need to scale it further? What is the actual effect? Then the second sentence suggests that it is related to an "effective deflection" (? a control surface either deflects or does not) The vertical tail / rudder chord is a misdirection as, if everything is set up correctly, all 'scalars' should be =1, which would allow the data for other inputs to stand. But above all that, this is an entirely new entry and the definition of it is NOT clear enough. It simply does not make sense on any level.
Example 2) This one may be simple or may not, depending on if you have our Hawk. Look at the fuselage side-on. It is purely a geometry issue, and this game claims to be very much based in accurate geometry:
The new flight model for Microsoft Flight Simulator relies on the shape of the aircraft to predict its aerodynamic behavior and we have almost entirely dropped the use of tables of data. Because of this, the correct definition of the aircraft's dimension data is of particularly importance.Direct quote again from the SDK there. Yet the ability to define the 'shape' is not there - we have length, diameter and centre position. No allowance for any fuselage that is not an almost-perfect cylinder. No allowance for area rule, nothing for the intake bumps, nor the high canopy. In the game, all you can define is a cylinder and the Hawk is outside that in so many areas but not consistently. It's also far inside that in other areas. Basically, if the game is reading the shape, then the shape is wrong so whatever flying characteristics depend on that are screwed.
In previous sims, we had full ability to adjust. If something wasn't right in the sim's calculations, we tweaked the coefficients and did not have limits artificially imposed. We were able to see what we were doing, refer to either the SDK or works on Aerodynamic theory (Roskam's are rather good!) and find a way to build the aircraft as correctly as possible.In MSFS, that ability has been taken away - the game has far too much control and we are very limited in what we are building. If we come across an issue because of the way the game has interpreted the files, our hands are tied - I am currently working on the PA38 Tomahawk and a rated pilot has commented on the flap behaviour: The aircraft's reaction should be a ballooning effect with a distinct pitch nose-down. The aircraft and flaps are defined correctly. The aircraft pitches nose-up. So I went to the coefficients and reversed the polarity of the entry for flap pitch, it still pitches nose-up. So I went to the aircraft editor, there's a section under [Flaps] which allows for aft movement of the CoL on flap deployment. Unfortunately, it actually gives forward movement of the CoL and any attempt to introduce negative numbers automatically rewrites it all to zero, so any adjustment of this exacerbates the nose-up tendency.
I have prided myself on accuracy within the constraints of the various sims prior to MSFS, this is a game and I don't think I am going to waste too much more time on it really because it has too much control without allowing the flight dynamics guy to adjust and derives everything from base aircraft (such as the C172). That's not appropriate for so many different types! ACES had a solid base in aerodynamic theory and it worked, but the environment around it was stifled. This game is a brilliant world and environment, but flight is based on "here's a problem, let's fix it with a random scalar"
-
In looking at the behavior it almost seems like a rounding or float to integer conversion where some precision is lost and is noticeable when transitioning between positive and negative. But who knows. So frustrating that Asobo won't help trouble shoot a really popular add-on plane. Is there a way where we can help by contacting Asobo ourselves?
-
Found a "tip" some time ago on the official forum, which seems to "work".
The source of the jerks seems to caused by these entries in the flightmodel.cfg:
aileron_up_drag_coef = 0.2
aileron_down_drag_coef = 3.9Simply comment these out and the jerks are gone.
;aileron_up_drag_coef = 0.2
;aileron_down_drag_coef = 3.9Probably not a scientific way yet it seems to works.
Any thoughts on this?
Marcel
-
@mgr That would be odd if aileron drag modelling caused pitching moments like that. My guess is that these coeffecients are there to model adverse yaw. Anyways, I don't think I can do this mod since I bought my Arrow through the M$ marketplace :( Might be interesting to look at other plane's values for these settings.
-
Also, that difference between up and down drag seems really high (20x drag coeff in the down direction). But not knowing how the sim treats those values, it is hard to say. I do also notice the excessive wagging on final which may be attributed to those settings. Can you try .2 and .39 and see what you get? If anyone can post these values for the Arrow II?
-
@sender46 Might be, but hard to say since I don't know what these numbers actually mean to MSFS. Still interested in what these values are for the Arrows that don't have this issue is. If they are the same, then that might rule out this being the source of the issue (although it could be a contributing factor along with something else). Trying .39 and seeing what the effect is might be a useful exercise for someone that can do it (I can't because the Marketplace version doesn't give access to the parameters).
-
@ajbarber In v0.10.3 these lines are:
aileron_up_drag_coef = 0.5
aileron_down_drag_coef = 2.8 ;3.9So still a high ratio of 0.5 to 2.8. I can't try changing mine to 0.39 at the moment.
Interesting that a number of other aircraft I've looked at don't even have those parameters in their flightmodel.cfg, e.g. Bonanza G36 Improvement Project v0.6.8, DA40-NGX Improvement Mod v0.9.0.1, Milviz Cessna C310R v0.1.0, FlySimWare Cessna C414AW Chancellor Beta 2.2.0, FlyByWire A32NX v0.8.0.
The only other aircraft I've found that does have those parameters included is the FlyingIron Spitfire L.F Mk IXc v1.2.0, which has them at these values (with a much lower ratio between the two):
aileron_up_drag_coef = 0.5
aileron_down_drag_coef = 1.0 -
@sender46 said in Pitch "jerks":
aileron_down_drag_coef
Defines the drag added by downwards[sic] aileron deflection. This parameter has a significant impact on adverse yaw. Increase downward deflection drag to get more adverse yaw. This parameter is multiplied by the aileron deflection angle. Default is 1. This can be scaled with the aileron_down_drag_scalar parameter in the [FLIGHT_TUNING] section and is further modified by internal coefficients.So it is 1 when not specified. Up default is .5. What are the values in the config for aileron_down_drag_scalar? The default for that is also 1.
-
@ajbarber aileron_up_drag_scalar and aileron_down_drag_scalar are not specified in v0.10.3.
For whatever it's worth (maybe nothing, being a completely different aircraft), in the FlyingIron Spitfire L.F Mk IXc v1.2.0 they are specified as:
aileron_up_drag_scalar = 0.15
aileron_down_drag_scalar = 0.85Interested to hear what @Delta558 makes of @mgr's "tip" and what comparisons with other aircraft might mean.