The FlyByWire team is making a separate autopilot system for its A320, so that future patches of MSFS won't break the FlyByWire A320:

Quote

In the meantime, we have increased our efforts to prioritize developing our own Autopilot system, to help avoid this particular issue in the future.

https://www.facebook.com/FlyByWireSimulations/posts/137398251465094

This is good news. Also, it's good news for other 3rd party planes that are released for MSFS, if they use their own separate autopilot system.  This means if those 3rd party planes have their own autopilot systems, the autopilot won't break for those planes either when Asobo releases a new patch for MSFS.

One thing I hope is that other freeware plane developers (who have made their own freeware planes open source of course) maybe contact and collaborate with the FlyByWire team on the autopilot.  It would be awesome if there was a community effort to get a common set of autopilot code that the freeware plane developers could all share and reuse (if it makes sense to reuse it, and the technical specifications favor a reuse of it, of course).

Edited November 30, 20205 yr by abrams_tank

To add, the custom FBW is almost there, I just tested and it is very very good (don't use it in the landing challenges 😛). These guys are awesome, especially Andreas Guther who did the initial custom FBW 😄 

Edited November 30, 20205 yr by omarsmak30

23 minutes ago, abrams_tank said:

The FlyByWire team is making a separate autopilot system for its A320, so that future patches of MSFS won't break the FlyByWire A320:

https://www.facebook.com/FlyByWireSimulations/posts/137398251465094

This is good news. Also, it's good news for other 3rd party planes that are released for MSFS, if they use their own separate autopilot system.  This means if those 3rd party planes have their own autopilot systems, the autopilot won't break for those planes either when Asobo releases a new patch for MSFS.

One thing I hope is that other freeware plane developers (who have made their own freeware planes open source of course) maybe contact and collaborate with the FlyByWire team on the autopilot.  It would be awesome if there was a community effort to get a common set of autopilot code that the freeware plane developers could all share and reuse (if it makes sense to reuse it, and the technical specifications favor a reuse of it, of course).

Amazing! No rant about the broken SDK in the FBW homes :). The mod code is already open source isnit?

(assumption solely based on the fact that its hosted by github) 

Edited November 30, 20205 yr by leprechaunlive

25 minutes ago, abrams_tank said:

The FlyByWire team is making a separate autopilot system for its A320, so that future patches of MSFS won't break the FlyByWire A320:

https://www.facebook.com/FlyByWireSimulations/posts/137398251465094

This is good news. Also, it's good news for other 3rd party planes that are released for MSFS, if they use their own separate autopilot system.  This means if those 3rd party planes have their own autopilot systems, the autopilot won't break for those planes either when Asobo releases a new patch for MSFS.

One thing I hope is that other freeware plane developers (who have made their own freeware planes open source of course) maybe contact and collaborate with the FlyByWire team on the autopilot.  It would be awesome if there was a community effort to get a common set of autopilot code that the freeware plane developers could all share and reuse (if it makes sense to reuse it, and the technical specifications favor a reuse of it, of course).

Yes it will be great if other freeware developers could use the FBW AP, but first they have to perfect it, which will not be easy to do, I'm sure they will eventually do a cracking job.

But do they not face the same problems as professional devs in that the SDK is incomplete? Or it could be a sign that the SDK is maturing nicely and the likes of PMDG, Aerosoft etc are bluffing a bit in a bid to outsmart the competition as the the first AAA standard aircraft will make lots of money for them, unfortunately all this is probably just wishful thinking.

4 minutes ago, eaim said:

Yes it will be great if other freeware developers could use the FBW AP, but first they have to perfect it, which will not be easy to do, I'm sure they will eventually do a cracking job.

But do they not face the same problems as professional devs in that the SDK is incomplete? Or it could be a sign that the SDK is maturing nicely and the likes of PMDG, Aerosoft etc are bluffing a bit in a bid to outsmart the competition as the the first AAA standard aircraft will make lots of money for them, unfortunately all this is probably just wishful thinking.

They'r just not really willing to learn a new way of develloping and coding. 

5 minutes ago, eaim said:

But do they not face the same problems as professional devs in that the SDK is incomplete? 

If we are talking about an A320 maybe not as it is a default aircraft and possibly they can piggy back on the default code  ... as opposed to making something more out threre like a Super Constellation or Beechcraft Starship .

1 minute ago, leprechaunlive said:

They'r just not really willing to learn a new way of develloping and coding. 

I think it's bit of both, not willing to learn new techniques or that it's just simply to early for the devs to have perfected new skills yet, but Asobo/MS have admitted that the SDK is still needs additional work to it before they're happy with it.

Has anyone asked Asobo how long they think it will take to complete the SDK? this question might be like asking how is a piece of string, but it would be interesting what their estimated timescale is regarding the SDK. This question might be a good one to ask at the next Q&A.

8 minutes ago, leprechaunlive said:

They'r just not really willing to learn a new way of develloping and coding. 

But the A320 and other fly by wire aircraft are a special case. There is absolutely no need for the vast majority of default aircraft to have custom autopilots. The FBW team are brilliant in what they've achieved, but a simple default aircraft like the C172 does not need a custom autopilot and no-one is "not willing to learn". That's an absurd suggestion. What do you think mod devs have been doing for the last 3 months?

The default a/p is perfectly capable of providing rock solid functions, if only Asobo would not keep fiddling with it and messing it up. It is in any case largely based on bog standard FSX a/p code and that is one thing that FSX generally did quite well. It does not need complex extra coding for the vast majority of ordinary functions: Heading, VS, FLC, LOC and Glideslope. The Turbo Bonanza a/p worked perfectly well before the update, as did many other default and modded aircraft.

So did the forthcoming DA62 until last week.

4 minutes ago, robert young said:

But the A320 and other fly by wire aircraft are a special case. There is absolutely no need for the vast majority of default aircraft to have custom autopilots. The FBW team are brilliant in what they've achieved, but a simple default aircraft like the C172 does not need a custom autopilot and no-one is "not willing to learn". That's an absurd suggestion. What do you think mod devs have been doing for the last 3 months?

The default a/p is perfectly capable of providing rock solid functions, if only Asobo would not keep fiddling with it and messing it up. It is in any case largely based on bog standard FSX a/p code and that is one thing that FSX generally did quite well. It does not need complex extra coding for the vast majority of ordinary functions: Heading, VS, FLC, LOC and Glideslope. The Turbo Bonanza a/p worked perfectly well before the update, as did many other default and modded aircraft.

So did the forthcoming DA62 until last week.

I know the problems with the defaults AP, wich is why a custom open source AP could be interesting, as it would not be as fragile as the Asobos one. Or even if it is, we would not have to wait forever to get a fix 🙂 the ideal solution would obviously be that Asobo stop breaking stuff, but, i doubt its gonna happen. 

Edited November 30, 20205 yr by leprechaunlive

3 minutes ago, robert young said:

But the A320 and other fly by wire aircraft are a special case. There is absolutely no need for the vast majority of default aircraft to have custom autopilots. The FBW team are brilliant in what they've achieved, but a simple default aircraft like the C172 does not need a custom autopilot and no-one is "not willing to learn". That's an absurd suggestion. What do you think mod devs have been doing for the last 3 months?

The default a/p is perfectly capable of providing rock solid functions, if only Asobo would not keep fiddling with it and messing it up. It is in any case largely based on bog standard FSX a/p code and that is one thing that FSX generally did quite well. It does not need complex extra coding for the vast majority of ordinary functions: Heading, VS, FLC, LOC and Glideslope. The Turbo Bonanza a/p worked perfectly well before the update, as did many other default and modded aircraft.

So did the forthcoming DA62 until last week.

Very well said. Let's be thankful that FBW is attempting to provide us a good working A320 A/P. Perhaps Asobo can follow in their footsteps and "enhance" their A/Ps to a higher level after FBW have shown them what a good working A/P looks like.

30 minutes ago, eaim said:

Yes it will be great if other freeware developers could use the FBW AP, but first they have to perfect it, which will not be easy to do, I'm sure they will eventually do a cracking job.

But do they not face the same problems as professional devs in that the SDK is incomplete? Or it could be a sign that the SDK is maturing nicely and the likes of PMDG, Aerosoft etc are bluffing a bit in a bid to outsmart the competition as the the first AAA standard aircraft will make lots of money for them, unfortunately all this is probably just wishful thinking.

From another thread here in Avsim, there was a freeware developer for one of the other aircraft mods (not the FlyByWire but another plane I think) that said the SDK is complete and comprehensive if the 3rd party uses new code that conforms to the new API.  The problem with PDMG and other developers with legacy code is that they want the SDK to automatically port over legacy code, or interface with legacy code.  Seems like PDMG doesn't want to write new code that interfaces with the new API.  I don't remember the thread and I can't remember who the developer was either.so you will have to look for that thread here on Avsim,

Edited November 30, 20205 yr by abrams_tank

The SDK is pretty much mostly complete in terms of core features - if you were able to code something for P3D, it's possible to port over the same code without any loss of functionality (with two notable exceptions: native weather data and terrain/navdata API's have not yet been implemented in the MSFS SDK). Working Title and Aerosoft have also confirmed this as well (read Mathijs Kok's thoughts on it here). Obviously there are other QoL features the SDK needs, but I am confident they will arrive in time. I personally don't believe it's a matter of SDK maturity or development time, especially when it comes to PMDG, but rather priorities. In their case, alongside MSFS, they are also choosing to work on the 737 BBJ, updates to the 777, and a new unannounced aircraft, all for P3D. Most payware companies are small, so putting out content for multiple sim platforms like that will obviously take a toll on development time.

 

As for the custom autopilot, it's something we were always planning to implement. However, given the rapid progress on our custom FBW system and the turbulent state of new sim updates, we realize it's something we should prioritize sooner than later. It will be built to work on top of the custom fly-by-wire system, and be released as open source, just like the rest of the aircraft (under the GPL v3 license).

57 minutes ago, leprechaunlive said:

I know the problems with the defaults AP, wich is why a custom open source AP could be interesting, as it would not be as fragile as the Asobos one. Or even if it is, we would not have to wait forever to get a fix 🙂 the ideal solution would obviously be that Asobo stop breaking stuff, but, i doubt its gonna happen. 

But the Asobo one is not actually fragile. It is not the basic autopilot that is wrong. It's what they keep doing to it that is wrong. Did you see Marsman2020's comparison video showing FSX and X plane heading capture using default aircraft, then comparing it with the latest MSFS update? Before the update the heading capture was almost perfect. For reasons that are a complete mystery Asobo have slowed down the heading capture to a crawl for no good reason. It was not the source of problems that people were having at all.

I have been tweaking the previous a/p code for weeks and I can confirm that, with a bit of trial and error, it was almost as good as the standard FSX basic a/p (which was actually very good).

There are so many other demands to make a mod or new product work well. It was rightly assumed by all concerned that the last thing they needed to worry about was the autopilot. Nearly all the reported concerns regarding the a/p with various aircraft were not the a/p itself but either flight model setups or badly tuned individual parameters to the standard a/p. The a/p itself was totally reliable, but people understandably started blaming it because they did not understand that the odd behaviour they had with some aircraft was not in fact the core a/p coding at all, but flight model mistakes or a badly setup individual a/p variables.

I can assure you that there was absolutely nothing wrong with the basic a/p code at all. The FBW Airbus is a completely different challenge as it needs an a/p that can do all sorts of non standard stuff like Fly By Wire functions, sophisticated VNAV and managed,FMC-based altitude and lateral functions that have always required custom programming.

Edited November 30, 20205 yr by robert young

39 minutes ago, IcemanFBW said:

The SDK is pretty much mostly complete in terms of core features - if you were able to code something for P3D, it's possible to port over the same code without any loss of functionality (with two notable exceptions: native weather data and terrain/navdata API's have not yet been implemented in the MSFS SDK). Working Title and Aerosoft have also confirmed this as well (read Mathijs Kok's thoughts on it here). Obviously there are other QoL features the SDK needs, but I am confident they will arrive in time. I personally don't believe it's a matter of SDK maturity or development time, especially when it comes to PMDG, but rather priorities. In their case, alongside MSFS, they are also choosing to work on the 737 BBJ, updates to the 777, and a new unannounced aircraft, all for P3D. Most payware companies are small, so putting out content for multiple sim platforms like that will obviously take a toll on development time.

 

As for the custom autopilot, it's something we were always planning to implement. However, given the rapid progress on our custom FBW system and the turbulent state of new sim updates, we realize it's something we should prioritize sooner than later. It will be built to work on top of the custom fly-by-wire system, and be released as open source, just like the rest of the aircraft (under the GPL v3 license).

Cool!  My understanding is, if a freeware plane developer wants to use the AP source code created by FlyByWire, they need to make their own plane open source, and also get permission from the FlyByWire team.  Hopefully, the FlyByWire team will consider making their AP code modular and reusable by other freeware plane developers.  Because this will be a benefit to the entire MSFS community, if the majority of freeware planes have their own customized AP systems, built on top of the FlyByWire AP code (if it makes sense for the freeware plane developers to reuse the FlyByWire AP code of course, and if you grant them permission to).

Edited November 30, 20205 yr by abrams_tank

27 minutes ago, IcemanFBW said:

The SDK is pretty much mostly complete in terms of core features - if you were able to code something for P3D, it's possible to port over the same code without any loss of functionality (with two notable exceptions: native weather data and terrain/navdata API's have not yet been implemented in the MSFS SDK). Working Title and Aerosoft have also confirmed this as well (read Mathijs Kok's thoughts on it here). Obviously there are other QoL features the SDK needs, but I am confident they will arrive in time. I personally don't believe it's a matter of SDK maturity or development time, especially when it comes to PMDG, but rather priorities. In their case, alongside MSFS, they are also choosing to work on the 737 BBJ, updates to the 777, and a new unannounced aircraft, all for P3D. Most payware companies are small, so putting out content for multiple sim platforms like that will obviously take a toll on development time.

Some hardcore P3D folks from P3D planet won't be happy to hear that 😛. But is true, unless PMDG want to use GDI+ to draw the gauges, which I guess at the current state is WIP unless they use MSFS modern way to draw.