I’ve been out of the loop for a little while and I’m ready to jump back into the sim. I heard that the stable build was recently updated, but I believe I was using the experimental build prior to my break from MFS2020.
I know this may sound like a dumb question, but I just always get confused with the 3 different builds and especially now since I’ve been a way for a little while.
Still experimental, as far as I know, at least if you want the custom flight plan manager, which I’d say it’s a must.
+1 for experimental. Yeah, it occasionally bugs something out in the plan but holy ■■■■, I tried to use the A330 mod last week and what a disaster the old one was. I can’t really see why they haven’t merged this yet.
Not all approach types are supported yet. I’m guessing that’s the biggest reason. But I’m happy to fly them semi-manually to enjoy the custom FPM.
They weren’t in the old default a320 trash version either so why not work on it in the dev version?
Oh they’re working on it. I believe they just need to iron out a few things. Like a lot of approaches require you to overfly a waypoint instead of turning earlier, which is the standard behavior of the FPM.
Experimental for sure. I was unsure about switching away from dev for the longest time, but can’t see myself going back now. The custom FPM is sooooo much better…
I prefer the developer version. I know the experimental version has custom flight planner. I can see the benefit of the custom flight planner if you do a lot of serious flight planning with SimBrief. But when I tried it with default flight planner. It caused more problems than it solves.
So I don’t see the benefit compared to the default flight planner since I never had any serious problems with it. Been flying with it for months and I always fly and arrive to my destination without issues everytime.
And the experimental version doesn’t have a working weather and terrain radar yet. So I don’t like using it. Since those radar are important to me when flying to difficult approaches like Paro.
What were the problems you had with it? I very occasionally see a flyback waypoint that has to be removed and then re-programmed manually but I don’t find this is nearly often enough to make up for the inability of the default flight planner to accept, let alone follow, most SIDs, STARs or Approaches according to their charts.
It’s like the flight plan that was created in the world map doesn’t get loaded in its entirety, causing some break points in the flight plan, missing lines, etc.
If I use the developer version and the world map to create a full flight plan with departure gate, SIDs, STARs, Approaches, up to the arriving gate. The full flight plan and their waypoints are always get loaded properly, and I never had any issues. Never flyback waypoint and ATC always follows the flight plan. So I always depart and land without any flight plan issues.
And I use navigraph navdata update, so all the waypoints, SIDs, STARs, and Approaches are all coming from the navigraph navdata even from the default world map flight planner.
I believe I used the dev version at some point as well, I just can’t remember which one I was using last before I took a break. Sounds like before trough where each one has different pros and cons from the other, so I guess I’ll just have to experiment with each one. Is there much of a difference between the experimental and dev version?
Also, so far today I just messed around with the latest stable version to get a feel for it again and recalibrate my throttle settings. I must ask though, what’s up with the brakes? They’re very strange now that I’ve come back. It’s like they’re delayed or something and sometimes seem to get “stuck.” Am I missing something here or is this just a stable version issue because they definitely weren’t like that before?
Even with the Navigraph data, the default flight planner can’t load in a proper approach to an airport if the necessary STAR has multiple final approach fixes. For example, let’s consider the OHSEA2 STAR for KSNA. When choosing this STAR, you get STIFF > JJAWS > PUZZL > MINOE which is the final fix for 02L. If you want to go to BHEAR, the final fix for 20R you’re SOL. The default planner only takes whatever is first in the navadata. This is if you try and enter via the MCDU. If you try and use the main screen, it inexplicably dumps the Seal Beach VOR (SLI) as the final approach fix for 20R. SLI isn’t even on the chart! FS2020 is plagued with this kinda ■■■■. Basically, I recall that any airport that has multiple final approach fixes for different runways on a single procedure, and any SID or STAR with a transition to/from vectors, suffers from this.
I guess if you really need to pick a different fix, then I understand if that becomes an issue. I myself never really need to pick a different fix.
In your specific example, if I need to fly to KSNA and the active runway is 02L. I just pick the OHSEA2 02L on the Arrival pattern and the RNAV 02L-Y from the approach list. And that’s it. That’s all I need and I just pick FLY.
And the dev version of FBW aircraft will take all the STAR and the Approaches with the ATC will follow suit as well and the autopilot follow them.
To me when I look at the flight path and as long as it doesn’t look weird like the above screenshot, I really don’t see the need to pick a different fix.
If the active runway is 20R and I want to stick with the same STAR of OHSEA2, then I just pick RNAV 20R-Y and pick the OHSEA2 20R Arrival Pattern, and it becomes this.
Or I can choose a different STAR that also positions to runway 20R as well.
Right, so in your example, and as I mentioned, the only correct procedure you can choose is the ILS to 02L. Unfortunately, the prevailing wind is such that you’ll basically never fly this procedure unless you make up your own weather or specifically look for the one or two opportunities per year when the winds switch.
Unfortunately, that path to fly the 02L approach to MINOE and then overfly the airport for the RNAV 20R is exactly the sort of FS2020 busted flight planning nonsense the experimental version is designed to avoid.
I guess it becomes a nonsense for people who actually know it’s nonsense… If it were me, I would actually accept it anyway and actually fly the procedure, which I never complained since I fly these nonsense procedures quite often, and I do manage to have the aircraft do these approaches accurately and land anyway.
It makes sense to see this as an issue if you’re familiar and actually know about the correct procedures. But for people like me, who likes to explore and visit airports and destinations that I never even knew existed (I actually have to look for KSNA that you mentioned, since I don’t know what airport that is or where it is), well I just take whatever approach and procedures at face value and assumed and accept that’s just how it is and just fly them anyway.
To me, even the second approach screenshot still makes sense to me since it’s just approaching the airport from the south, turn left, then make a ‘U turn’ to face the runway and land. I never see this as a problem. I thought that’s just how it is.
If I don’t like that approach, then I can just pick another STAR that comes from the north.
Which comes back to the OP’s question. Assuming OP is at the same level of understanding as I do, then I would think the dev version would be better for them than experimental. Like I said, experimental version doesn’t work well with default flight planner. So you would actually need to do “proper flight planning” process to have the experimental version working the way it suppose to. If OP is well versed in doing it, or if they’re planning to do the whole proper flight planning process then yes the experimental version would be the one to go.
But assuming if we just want a point and click flight planning process and just accepting whatever it is that the flight planner give us and just fly it. I just don’t think having the experimental version is worth using since it’ll cause more problems than it solves. That’s why I said the developer version could be the one to go for people like me.
Yes, your explanation is why I fly the dev version rather than the experimental version.
With the dev version - have you found an actual way to avoid the flight plan mess up that (often) happens when the approach phase is activated? I think I read it’s sometimes called “the fly-back bug”?
Yeah, make sure you have the approach procedure set up before you start the flight. If you add the approach to your MCDU after you already start your flight session, that’s when the flyback bug happens.
That’s why I always create a full flight plan, with Departure, Arrival, and Approach patterns setup on the world map before I even press FLY. so the entire full flight plan is loaded when you start the flight. By the time the approach phase is activated, there’s no flyback bug because the whole approach is already part of the flight plan.
Ok thanks, I’ll give it a try tonight!
I just finished my flight stream on my YouTube channel. It’s currently still processing so it’s not showing the flight planning part yet. When it does, you should see how I do my flight plan on the world map that always works without issues for me.
