V1.2 Update: Honest Review - A Complete Disaster for IFR and Online Operations

[jvtbalds]

Hello everyone,

I need to express my profound disappointment with the current state of the Fokker 100 following the V1.2 update. As a huge passionate fan of the F100, I waited 3 years for this release. However, what we have right now is a product that is not only discouraging to fly but an absolute disaster for anyone trying to replicate real-world IFR operations, especially in online environments like VATSIM.

To give you some context on why this update feels like an experimental build rather than a finished product, here is a breakdown of my two most recent flights:

Flight 1: SBCT to SBSP

During the descent via the STAR ANISE1A/OGTAL, the aircraft completely failed to comply with the arrival altitude restrictions. It flew way above the fixes where the restrictions were explicitly programmed as "AT OR BELOW."

I flew the ILS V for RWY35L at SBSP and executed a missed approach at the minimums.

While the initial missed approach profile was followed decently, the holding pattern afterward was completely ignored by the aircraft. This directly contradicts the response I received on a previous support ticket, where I was told the holding logic was being overhauled for this update. The plane's behavior here was, to put it mildly, ridiculous.

You can check the hold """"procedure"""" clicking here (YOUTUBE)

The ATS (Auto Throttle System) behavior remains absolutely erratic. It was so chaotic that it honestly made me want to close the sim and not touch the Fokker 100 for a long time.

You can check the ATS poor behavior clicking here (YOUTUBE)

Flight 2: SBSP to SBCT (Clean Reinstall)

Giving the aircraft the benefit of the doubt, and assuming the issue might be on my end, I did a completely clean reinstall. I flew the reverse route. The departure (SEDLO1A/SOVSI), cruise (UZ85 - RAXIT), and descent via the RAXIT2B arrival went smoothly.

Then, the nightmare started again:

The logic for intercepting the Glide Slope and Localizer is still very, very bad. On the ILS W for RWY33 at SBCT, upon hearing the "loc captured" aural, the aircraft aggressively banked in the opposite direction of the localizer course. After blowing through the course, it rejoined the final approach in a descent, crossing the IF well below the minimum altitude. A total disaster.

Once again, I initiated a missed approach at minimums. The aircraft followed the profile, but just like the first flight, it ignored the holding pattern at the CT171 fix. I noticed the FMS doesn't even automatically insert the hold into the missed approach profile; it just leaves the fix as a FLY OVER waypoint (marked by the triangle symbol). I manually inserted the hold at CT171 according to the charts, and the execution was completely below acceptable standards. Extremely poor and amateurish.

You can check the go around and hold entry """"procedure"""": clicking here (YOUTUBE)

The image below shows the LOC capture behavior and the hold entry """"procedure"""":

Still trying to give it a chance, I programmed the DODRA fix into the FMS and set up a manual hold (inbound course 335, direct entry, right turns) just to see if the plane could fly a basic hold. The execution was completely disastrous. The aircraft seems utterly incapable of maintaining standard rate turns or staying within the bounds of a standard oval holding pattern. This is simply unacceptable for an aircraft that took 3 years to develop.

You can check this hold entry clicking here (YOUTUBE)

To make matters even worse, when I attempted to re-insert the ILS W approach for RWY33 starting from the ALGUD fix, the entire route was completely wiped from the FMS. I immediately lost all lateral navigation capabilities. It became impossible to rely on anything other than basic HDG mode, forcing me to ultimately fly the entire ILS procedure manually in raw data. This level of system unreliability during critical phases of flight is staggering.

Finally, completely exhausted from a flight where everything critical went wrong, I decided to land. Upon disconnecting the autopilot, the nose pitched down aggressively, the exact same bug from V1.0. I just closed the simulator without even finishing the flight. It wasn’t worth the headache.

A Serious Question to the Development & Beta Testing Team:

1. Was the beta testing team unable to verify these fundamental behaviors before pushing this update?

2. Did no one fly a standard missed approach to ensure the aircraft can perform something so basic and necessary?

3. Did no one test en-route holds, or holds at custom fixes, to observe this flawed execution?

4. Did any beta tester actually fly a normal IFR flight from start to finish without noticing that what I experienced in two standard operations is completely unacceptable?

After several flights, while I still think the initiative to develop this aircraft is fantastic, I am deeply disappointed across the board. The successive bugs, the erratic behavior, and the inability to perform basic IFR procedures should not exist in an aircraft that costs $90 (a premium price tag!!!).

I’ve submitted multiple tickets, trusted the promises of improvements, and was more than willing to contribute however I could.

The support team has been responsive, which I appreciate, but the aircraft itself remains "more of the same."

From where I’m sitting, I have an experimental version in my hands that is nowhere near ready for a flight that doesn't end in sheer frustration.

Best regards,
Joao Vitor

[Martyn]

Hi Joao,

Thanks for the comprehensive feedback.

Whilst we acknowledge that there are, and will continue to be, fixes and improvements that need to be made to the complex AFCAS/ATS/CDU behaviour, we, and presumably the thousands of other owners, aren't encountering this same level of frustration with the current build.

Internally we have flown thousands of flights all over the world, including many in the past week with v1.2. Those are IFR, sometimes on VATSIM, by the development team, by real world F70/100 pilots, with holds and missed approaches etc. Countless owners have done the same, including many streams available on YouTube and Twitch etc.

We will investigate your specific examples and get in touch with you directly if we require any further information or feedback. We have extensive debugging tools for CDU sequencing, hold behaviour etc, so we should quickly be able to identify any issues arising from your examples, which could be exposing some underlying weaknesses in the current logic.

Please note that missed approaches and holds are currently being overhauled significantly, but as per the v1.2 changelog, those changes are not included yet. We expect them to be included in v1.3. That said, we are not seeing this degree of issues even with v1.2. We wouldn't have released the product at all, let alone the subsequent updates, if we had. Hence us delaying release by many months until we were happy.

Ultimately, we are very happy with the current product and the feedback that we are seeing from the community, content creators and our real world F70/100 pilots. We are always open to critical feedback though, and continue to work hard to address any issues with the product to the best of our abilities. Hopefully v1.3 will deliver the fixes and improvements to address your frustrations.

Given the level of frustration that the product is causing you, I'd also like to point out that you're welcome to ask our customer service team for a refund if you'd prefer that option.

EDIT:

We have now started reproducing the specific procedures shown in your report using the same routes and approach setups. An initial review has already identified a potential issue in the localiser capture steering logic in certain conditions, so thanks for reporting that, and we are also checking how the two missed-approach holds are represented and imported from the navigation data.

We are separately investigating the approach re-selection that removed the route, as that should never leave the aircraft without a usable active flight plan.

Thanks,
Martyn

[jvtbalds]

@Martyn

Hi Martyn!

Thank you for your detailed reply and for taking the time to thoroughly investigate the specific scenarios I provided.

I appreciate the offer for a refund, and I must admit I genuinely considered taking that route after my flights today. However, upon reflection, I believe that would be unfair to the immense effort your team has poured into this project over the last three years. Developing a complex add-on for a classic aircraft like the Fokker series especially knowing how incredibly rare it is to find airworthy airframes for reference and data gathering nowadays is a monumental task, and I deeply respect the work that has been accomplished so far.

I want to clarify that my frustration does not stem from an inability to understand the complexities of coding systems like the AFCAS, ATS, or CDU. My sheer disappointment occurred because I had previously reported these exact same behaviors via the ticketing system and was explicitly assured they would be resolved in today's v1.2 update. Discovering mid-flight, during critical IFR phases, that the aircraft was still exhibiting the same issues was incredibly disheartening.

I would also like to offer a sincere apology if the tone of my initial messages (here or via support system) came across as overly harsh or inelegant. My deep passion for the Fokker 100, combined with my strict professional standards regarding instrument flight procedures, certainly fueled my strong wording in the heat of the moment.

To ensure that my feedback is properly tracked and to better assist the development team, I have officially submitted the entire content of my original forum post, along with the unlisted video references, through a new support ticket (Ticket #98051).

I am very glad to read your edit and to know that the team was able to reproduce the localizer capture logic issue, as well as investigate the critical FMS route-wipe bug. Seeing the team actively debug these specific scenarios gives me confidence that v1.3 will deliver the necessary stability for serious instrument flying.

I will continue flying the F100 and testing its systems. If I encounter new anomalies or experience these same bugs under different operational scenarios, please let me know if I should feel free to continue reporting them via new support tickets. I am more than willing to keep contributing to the refinement of this aircraft.

Thank you again for your time and transparency.

Best,
João

[jvtbalds]

Just a quick follow-up to my previous reports.

For testing purposes, I just completed another flight to further evaluate the holding and FMS behavior, this time flying from SBCT (Curitiba) to SBFL (Florianópolis).

Here is a breakdown of what I found:

Routing & Setup: I departed from SBCT RWY 15 via the PONLU1A SID. After PONLU, I flew direct to MATSA to join the VOR Y RWY 32 approach at SBFL. I intentionally skipped the DME arc and went straight for MATSA just to test the F100's behavior on the published hold (inbound course 322, right turns).

Speed Management: I manually inserted the hold data into the FMS based on the charts. The FMS correctly calculated a best hold speed of 178kts, and the aircraft maintained this speed perfectly during the procedure.

VNAV Calculation: Because I didn't insert a STAR for SBFL (I just flew DCT MATSA after the SID), the FMS completely failed to calculate a vertical descent profile. No T/D (Top of Descent) appeared on the MFD, and no vertical navigation calculations were available in the FMS. It's not a huge deal in practice since I can just apply the standard 3:1 rule and do the mental math for the descent, but it clearly points to a flaw in the FMS VNAV logic when a STAR isn't present.

Holding Execution: Even though the FMS correctly processed the hold data and accurately determined it needed a parallel entry based on my heading, the actual flight execution was quite... strange. I stayed in the hold for 5 full circuits, and all of them were unsatisfactory. The aircraft flew erratically, couldn't maintain constant turn rates, completely lost the standard oval shape, and drifted laterally off the desired profile.

Missed Approach Hold Missing: Looking at the missed approach profile for the VOR Y RWY32, I encountered the exact same bug I reported in my earlier flights. The FMS only inserts the missed approach fix as a simple FLY OVER waypoint and completely ignores the published hold. I had to manually insert the hold into the FMS to execute it. Based on the real-world Fokker 100 manuals, this contradicts the actual aircraft logic, where the published missed approach hold should be automatically populated.

To expand on the autopilot disconnect issue: the pitch-down tendency remains entirely unresolved in this version. This flaw immediately forces the aircraft into a destabilized state right at the most critical phase of flight. Operationally speaking, this becomes particularly severe during non-precision approaches, where maintaining a strict, continuous vertical descent angle manually down to the minimums is absolutely necessary.

I just wanted to add these findings to my open ticket/thread to give you guys more data points on how the VNAV, FMS sequencing, and holding logic are currently behaving. Hope this helps narrow down the issues for v1.3!

[Prattpt6]

The approach phase after latest update seems to be broken. On approach the autothrottle will always goto TOGA even though the bug is set for final approach causing the plane to overspeed, also GS doesnt capture. I never had this issue with previous version. So every approach Ive had to hand fly, no AP. I also find sometime AP will randomly disconnect on final as well..

[Martyn]

As per my reply on the MS forum, we’re not aware of those issues and didn’t account them during our extensive v1.2 testing. Please submit a support ticket so we can investigate - https://support.justflight.com/support/tickets/new

[Martyn]

Thanks for the additional feedback, João. We are busy investigating now.

We believe that both the LOC intercept and flight plan wiping issues are fixed.