Side slip implemented natively?

Getting back to this aspect of the original inquiry, I would be willing to wager fuselage_lateral_cx may have something to do with a lack of descent during slips especially in the default sim aircraft. It was discussed a few months ago here (https://forums.flightsimulator.com/t/wrong-default-fuselage-lateral-cx-value-suggestion/584405) and here (Adverse Yaw | Slip | Aircraft list - #68 by HomieFFM).

Most Asobo planes are at 0.4 but the C172 AS1000 is set (still to this day) at 4.3, which is more than twice the drag of a parachute. I would be interested to see what your impressions are of slipping with the C172 AS1000 as compared to a different Asobo aircraft (with a value of 0.4).

1 Like

Good point. I’ve just checked the flight model of C172 Classic and C152 and noticed that they both are set on 0.4 by default. Modified the C172 g1000 and a simple take-off with 15 knts side-wind is now easier to manage.

For a C172, a value of 0.8 would seem to be more appropriate ( cylinder 0.8, vs sphere 0.4)

The 4.3 seems, as noted above, to be a typo.

Comparing the Asobo C172 1000, vs Asobo SP Classic, the flight model files seem to have a great number of differences (For effectively almost the same plane), the G1000 model having a lot more parameters that are missing from the Classic.

This would seem to indicate that the C172 Classic (Premium/Deluxe) is not being updated “in sync” with the G100 Model.

Very strange, and a QC big RED FLAG – they both cannot be correct.

FYI: The wb-sim C172 has a value for “fuselage_Lateral_cx” of 0.8, and its Side Slip characteristic seem to be a lot more reasonable than the default Asobo Planes of 4.3

The wb-sim C172 FLOAT has in increased value of 1.0 (to account for the floats)

The big take away though is WHY do the two Asobo version of the C172 have such different Flight Model parameters. (The only difference should be a slight WEIGHT value, to account for the difference is Instrumentation weight)

3 Likes

Yeah the two probably shouldn’t be compared through the lens of that one parameter alone. They diverge in plenty of other areas too and, like you implied, with little to explanation as to why.

Perhaps bringing up the C172 with the 4.3 value was more a distraction than a point. I was just trying to see if the OP would agree that the supposed peculiarity they are noticing may have something to do with fuselage_lateral_cx. If the suspicion is that 0.4 isn’t enough (btw, it isn’t) and doesn’t lead to enough descending during a slip (it doesn’t), attempting a similar maneuver with the hyper-exaggerated value would provide some context. However, this may be more like determining whether a meal was under-seasoned by eating a spoonful of salt afterwards.

I agree that 0.8 is much more reasonable, both in theory and in the sim. In fact, 0.8 as a default for all planes would be much better than it is now.

Well, honestly I don’t believe those improvement mods from non pilots. How does one suppose the correct flight behavior without any experience in the air. That said, I would guess some of them were indeed tuned by professionals and would make the model more realistic in the sim. I can’t comment on the specific value as I never intended to open any config files, but I see an overall trend of inconsistency across the platform.

Engineers design aircraft not pilots. Pilots provide input yes but it’s the design team that make it happen. Don’t get me wrong there are some very knowledgeable and experienced pilots who also contribute but the point is you don’t have to be a pilot to do stuff like this.

Agreed. Knowledge of aerodynamics and even more so the way the SDK implements things, coupled with systemic testing are the basis for good FM development.

(And some of the most capable aircraft devs are not pilots - but they know how to take information from all sources, including pilots)

Being a pilot, I tend to agree that engineers and developers are often better suited to translate numbers into numbers (i.e. RL to sim).

But, like all things, that’s not an absolute statement.

I’ve seen devs in all good faith make choices that result in sim aircraft that fly nothing like the actual item. Sometimes subjectively. Sometimes otherwise.

And I’ve even had the experience where, should you politely bring this to their attention, you get told that you clearly don’t understand how planes fly.

Until you point out that you might have several hundred hours in that particular aircraft.

Now, whether I flew in the aircraft or not shouldn’t have any effect on the factuality of the issue I was addressing. But the tone of the conversation will often change considerably.

Point of all this being, there’s no guaranteed, completely unbiased arbiter of truth here. The best products, real or sim, come from collaboration.

1 Like

Can you say more about this? What aspect of the transition do you find unrealistic? (genuine question)

I must assume that comment was NOT directed at me !!
35 year with a PPL. 40 years in the Aerospace industry. 40+ year with Computer flight simulators. 30+ years developing code for flight simulators. RL pilot on Wb-Sim Dev team. (C172 Improvement Mod)

No, its not me you could be referring to :rofl:

1 Like

I think the difficulty comes from a stigma where most of 3rd party developers support tickets on this matter (Flight Models) start with “I am a real world pilot”, without stating what type they flight or what is their level of experience they have with similar aircraft and even worse explaining what they were trying to do when the fault or problem happened.

Let me give you an example, when Sting S4 was released it was tested all internally by real world pilots of the Sting S4, the product was also sent to the aircraft engineer that create the airplane IRL and performed the wind tunnels tests, which in turn confirmed the behaviour in MSFS was accurate. The pilots also validated the flight model was accurate to what they experienced IRL, this is a process I do for all my products when it reaches the final stages.

Despite of this, there were initially some heavy criticism because the aircraft felt slippery and very light (well it is an ultralight funny enough) and this shouldn’t be the case in the view of some, despite the fact that 5 pilots that own this aircraft nagged me several times during the developing process to please leave the slippery behaviour as this is how it should be IRL. I still have the real world videos showing all the flight data they sent as an example.

There were also some youtubers on day one claiming the flight model was faulty because you could not STALL a wing and go to a spin, a behaviour that is also very particular of this aircraft because of it aerodynamics characteristics and IRL pilots insisted in me replicating this behaviour. There was another that complained the product was unflyable when it tried to land with a 30kts xwind factor when the real aircraft max xwing factor is around 9kts max…

3 weeks after release I received the dreaded “I am a real world pilot email”, this particular person criticised everything about the FM, I am a very open minded developer and accordingly instead of rejecting his allegations, I invited this person to discuss with our real world test pilots his findings, it turned out this person was a pilot of helicopters… I am not going to say how that ended but you can tell why these types of emails is starting to get a bit tiresome for some 3rd party devs.

You are correct collaboration between everyone is KEY to get as closer as possible to behaviours from real life into the simulator, this is a process that we follow inside FSReborn during many weeks, sometimes months, where real world pilots of the type test the product flying characteristics alongside with normal simulators users, and we find a balance between both type of users to bring the best customer experience possible for everyone.

There are many variables that will affect how a product will perform inside MSFS, not only pilot skills, but hardware sensitivity, hardware calibration, hardware reactivity, flight model accuracy, MSFS realism settings, MSFS live weather situation, etc, etc, etc. Tweaking a FM is an art of balancing all correctly so not only the product replicates real life behaviours but also allows users to instinctively follow the aerodynamic forces into action to fly it properly.

Since collaboration is key between all of us for the best outcome possible for the community, a better approach when seeking help from developing teams would be: “I am experiencing X when doing Y and I would expect to feel Z, is my expectation correct?” this opens the channel of communications much better, and if you are communicating with a good developing team I can warranty you will receive a much better support and experience rather than starting your email with “I am a real world pilot…”, with the first statement the ball is now in the dev team court to ask more information, such as, ok how, when, what weather, what hardware you have, can we replicate? is always better to make a dev team realise there is an issue by making it drive to its own conclusions.

Just my two cents, all the best

Raul

7 Likes

Acceleration in and out way to high … its as if the plane has little to no mass or inertia.

Great advice … works in so many other aspects of RL as well !!

1 Like

Acceleration as in how quickly a rolling secondary effect of the rudder will develop when entering a side slip, or how quickly increased drag/-vs will develop in a forward slip?

The first for sure – difficult to judge now quickly the drag develops … maybe can tell by looking at the g-force parameters, as you do not FEEL them in the simulator.

1 Like

Thanks for the great post! How did you manage coding your slip behavior?

What’s fascinating about this thread is that a sim is an illusion created by moving the viewport/camera along a curve that is manipulated by inputs from the controllers and the sim. This causes our brains to experience the sensation of flight that is so real we forget it’s a sim. Kudos to the devs for creating this wonderful machine.

I flew my WMF-5 in some really bad weather from Victoria to Friday Harbor. The wind was 40 knots on the ground. The crosswind was too high at Friday Harbor, so I had to divert to Oak Harbor. I crawled against a 40 knot headwind, and when I arrived at Naval Whidbey Island airfield I still had a significant crosswind. That was the first time I performed a side-slip landing in the sim, and it was textbook. I’ll never forget that flight.

So, like I said, test the parameters in normal and extreme conditions.

for M500 we still at it… in hence why I am reading this topic hahahaha

R.

2 Likes

Back to the question of native support, I did some testing in the wonderful FSReborn Sting. (Great flight model, BTW). I climbed up to 2000ft with winds 270 at 2kts, turned final and performed a few down slips. Without flaps it was very hard to lose altitude, but with flaps it helped a lot. The TAWS system started throwing fits telling me “500, pull up”, and it seemed to kick the nose up with each announcement. Fun stuff!

So, if by “native” we mean “fully integrated” I’m not so sure. I’ve never flown with anything but steam gauges. Anyone have thoughts?

If by ‘natively’ we mean ‘will an appropriately Asobo SDK modelled aircraft demonstrate expected side-slip behaviour with the controls positioned appropriately’, then the answer is yes…but with the potential caveat given by @N6722C that it may not do so smoothly.

The SDK supports it. The rest is down to the aircraft designer and the pilot flying.

2 Likes

Great post, and I appreciate your perspective!

I have no doubts that it must be difficult and sometimes frustrating to develop something complex like an aircraft and release it to the public.

But I think we are in agreement that the best product is created when hard data is blended with pilot input, particularly with those that have experience in the real thing.

And provided that the input is constructive in nature of course. :slightly_smiling_face:

My best in return.

1 Like