1 hour ago, fppilot said:

a) there is user friendly capability to customize aircraft configuration files

Other than the locked up deluxe/premium aircraft, editing aircraft is even easier in MSFS than in P3D. And you don't even have to modify the core sim files, it can all be done through the Community folder, which eliminates the hassle of having to remember your edits and restore them after updates like in older platforms. So, is it super easy? No, you still have to use the SDK or edit the .cfg files manually, but it is a better system than we had in P3D. And since there is no more .AIR file, it is much easier to tweak aircraft performance - no need for some AIR file editor or anything like that. Now, if 3PDs choose to lock their aircraft up like the deluxe/premium aircraft, that would be disappointing, but we have no indication that they'd take that approach. It is true that there are some new parameters that are not documented in the SDK documentation yet, but I've learned what some of them do already and have used them in my tweaks, like the one for the CJ4, but more documentation would be helpful. That said, and let's be super clear about this, NONE of the flight dynamics parameters are well defined in the FSX/P3D/ESP SDK; and those were just extended from the previous versions of FS. 20 years in the history of FS and flight dynamics parameters never got more than a one sentence description of what they did, so it's not like developers had a lot of assistance from that SDK. They've never had good documentation. I hope that changes with MSFS in the coming months, and Asobo has indicated that they will be adding much more detail when they have some cycles available to dedicate to it.  But in the worst case scenario, they're no worse off than they've been for the last 20 years...

1 hour ago, fppilot said:

b) effective partnering with add on avionics developers like RXP

I'm not sure what partnering is required? The move to HTML/CSS/JS has made developing gauges and avionics much simpler. Two weeks ago I had never written a line of javascript in my life. I'm not a developer. However, in collaboration with a few other members of our community, in one week we've added nearly 15 screens to the CJ4 Proline FMS. Now, they're not all finished, we realistically have weeks of work left given that we all have full time jobs, but...come on...if I can build functional FMS pages with less than two weeks of development experience, surely the professionals can do it. It took us a couple hours to add the ability to go direct to any arrival or approach fix. What kind of partnering, exactly, do they want? It's javascript, HTML and CSS. These are industry standard technologies that kids are learning in high school. In P3D/FSX I could have never done this - I don't know how to make a .GAU file. I don't know how to make a .DLL. I don't know how to make a .CAB file. But MSFS has made all that obsolete and introduced modern, simpler and easier to use technologies. Sure, some of the 3PDs want to port their .NET/C code over and for that, they need to use the WASM module I guess, but from personal hands-on experience, there's nothing stopping someone from building a GTN750 today that relies either on in-sim nav data or uses external nav data, like Navigraph.

I totally understand the frustration with bugs, and I also completely agree that the default aircraft need work - that's why I rolled up my sleeves. Weather is the most annoying bug for me right now, so I totally get that. There are whole sections of the SDK documentation that need work - and I've made that point in a few threads, so I'm not defending Asobo here on that front, but it is also worth noting that to make the changes we've made so far to the Proline, we haven't needed the SDK at all. Because it's all written in common, standard programming languages. There's no secret sauce. It's all out there and freely available, there are samples included already and you can pick through the code, all in the clear, for all the default instruments, avionics and aircraft - and that's been our biggest resource for modeling new functions.

What's been made available to developers already, especially from an avionics development perspective, is a whole generation newer and better than what exists today in P3Dv5, and it is much easier to work with, as far as I can tell. I do have empathy for the 3PDs - learning new technology can be frustrating, but if they're really complaining, I wonder if it might be because of a lack of ingenuity, a resistance to change or an unwillingness to learn new things.  Let's be honest - those complex panels running on 20 year old development languages are inefficient and cause performance issues, and you just have to take a stroll through the P3D forum to read all about it...Coherent and CSS with JS/HTML gauges allow for optimizing panels and instruments to only use GPU resources to draw what needs to be redrawn, saving on resources and improving FPS. Sounds like a pretty good upside for end users. I'll also note that I've run into more than one 3PD that I respect in the MSFS SDK discord and the ones that are there are already building for the new sim and making the effort to learn the new development languages. Will it take some time for them to nail it? Sure - they're learning something new - that's okay. But for those that are unwilling to make an effort, well...they're the ones that will be left in the dust.

Take a look at the A320NX team - I've been helping out on a couple modules. They are working on everything from a new FBW system, new flight dynamics, new autopilot, modeling nearly every system in the aircraft - all with no more SDK details than the 3PDs. It will be a lot of work, but it's possible because of the development languages - JS, HTML, CSS, WASM - these are all languages many, many, many people know how to use. So people with literally no past flight sim development experience can dive in and do amazing things quickly. This is nothing short of revolutionary for the community, even with the warts and growing pains that come with any new platform...in the meantime, P3Dv5 still runs just fine for those with less patience.

There are bugs and every piece of software could always use another six months of QA time, but...we are where we are and the future looks really bright to me from my short time under the hood...

3 minutes ago, DavidP said:

The days of clock, egg timer etc. like when I gained my Instrument Rating in 1985 are over

might be, be it is still good airmanship to be able to fly needle, ball and airspeed in partial panel.

Almost anyone can fly IFR with modern glass if everything is functioning, even us hobby flyers w/o an instrument rating.

1 hour ago, DavidP said:

In my country there are very few radio navaids now. All IFR aircraft are mandated to be fitted with atleast TSO129 GNSS and all routes are now RNAV routes. I teach IFR and we do teach radio aids if a student requires it (usually those aspiring to fly professionally) but it is mostly GNSS. I fly 1 NDB approach annually to simply keep my ability to be able to teach it valid.

The days of clock, egg timer etc. like when I gained my Instrument Rating in 1985 are over.

I have flown once from Moorabbin airport. The was a school that mostly operated Warriors as far as I remember. None of them had GPSs at the time. And CFI who flew with me didn't have instrument rating 🙂

Well it's true glass take over and feeder routes and approaches nowadays require RNAV equipment. Yet  the world is still full of VOR, and up north there are plenty of NDBs. US NAVY still use sextant and celestial navigation. GPS outages are not uncommon, also GPS signal can be easily jammed. There are tons of notams about GPS outages here and there. So over-reliance on technology is double edge sword. We must used it, but not get reluctant to skip basics. I'm personally not in the business preparing operators, I still teach pilots.

2 hours ago, cwburnett said:

There are bugs and every piece of software could always use another six months of QA time, but...we are where we are and the future looks really bright to me from my short time under the hood...

Thank you, for what has to be one of the best replies to a member's topic to date on Avsim.  Brilliant, I learned a lot from your answer..

2 hours ago, cwburnett said:

 

That was an absolutely brilliant and eye-opening answer. I too saw many people complaining about the SDK, and maybe some areas do warrant it, but I didn’t know that the modern languages used and adopted by Asobo means that anyone with decent programming skills can work on an aircraft.

It really makes the other addon developers look lazy for not embracing the new and sticking to their legacy codebases and refusing the modern possibilities of optimization. 
 

Development on the scenery front is almost a similar. Asobo have implemented the scenery SDK and made it so simple such that your everyday Joe is now making their own houses and city landmarks in Blender and distributing them for free to everyone. This explains the massive influx of scenery addons for various cities and POI’s around the world floating around discord and the forums. 
 

7 hours ago, ahsmatt7 said:

You do serious flying? What IFR? So VFR work isn't serious flying? Go get a life dude....

 

Some of us fly in real time when there are IFR conditions.  And I have a schedule I fly to and from selected sporting events. When I encounter VFR conditions I am enjoying MSFS very much.  But when I encounter IFR conditions on approach and landing is a different story.

In real life I can tune GPS gauges in a fraction of the time it takes in this sim with the default gauges, and in previous sims I can tune RXP gauges in just a little more time than in real life.  And so far I have not found a method to select a waypoint in a flight plan for a Direct To.  And at times when I clear out an interim waypoint the G1000 in the DA62 clears out that waypoint and everything else that followed it.  Very frustrating.  And in the DA62 the G1000 failed to acquire the approach.  Yesterday I reacted by activating the approach again.  It turned me back to the IAF.  But when it got there, despite what was showing on the G1000 flight plan screen, it continued me backwards on my flight plan to the VOR 55 miles previous to the IAF.  At that point I attempted to go Direct To the IAF again and it extinguished everything in the flight plan following the IAF, including the destination airport.  I went to FSX SE and flew the route again. 

To get around the cumbersomeness in manually entering flight plans I have begun using LittleNavMap to write .pln files.  They are structured fine in LNM and some load fine MSFS with all the waypoints.  Others load with only the departure and destination airports and no interim waypoints.  And those load just fine into FSX SE.

There are at least three (3) add on GPS gauge developers out there. Try reaching out to them to inquire about their MSFS developement experience to-date.

Edited September 4, 20205 yr by fppilot

16 minutes ago, fppilot said:

Some of us fly in real time when there are IFR conditions.  And I have a schedule I fly to and from selected sporting events. When I encounter VFR conditions I am enjoying MSFS very much.  But when I encounter IFR conditions on approach and landing is a different story.

In real life I can tune GPS gauges in a fraction of the time it takes in this sim with the default gauges, and in previous sims I can tune RXP gauges in just a little more time than in real life.  And so far I have not found a method to select a waypoint in a flight plan for a Direct To.  And at times when I clear out an interim waypoint the G1000 in the DA62 clears out that waypoint and everything else that followed it.  Very frustrating.  And in the DA62 the G1000 failed to acquire the approach.  Yesterday I reacted by activating the approach again.  It turned me back to the IAF.  But when it got there, despite what was showing on the G1000 flight plan screen, it continued me backwards on my flight plan to the VOR 55 miles previous to the IAF.  At that point I attempted to go Direct To the IAF again and it extinguished everything in the flight plan following the IAF, including the destination airport.  I went to FSX SE and flew the route again. 

To get around the cumbersomeness in manually entering flight plans I have begun using LittleNavMap to write .pln files.  They are structured fine in LNM and some load fine MSFS with all the waypoints.  Others load with only the departure and destination airports and no interim waypoints.  And those load just fine into FSX SE.

There are at least three (3) add on GPS gauge developers out there. Try reaching out to them to inquire about their MSFS developement experience to-date.

Kind of interesting that you have nothing to say about CWBurnett's post above, which basically blew your argument out the water. Instead you continue with this tiring and tiresome temper tantrum. 

It is encouraging to see the SDK and 3rd party updates all over their development roadmap.  At least they see it as a big priority.  Hopefully getting the default stuff improved is coming soon as well.  

7 hours ago, cwburnett said:

I'm not sure what partnering is required? The move to HTML/CSS/JS has made developing gauges and avionics much simpler. Two weeks ago I had never written a line of javascript in my life. I'm not a developer. However, in collaboration with a few other members of our community, in one week we've added nearly 15 screens to the CJ4 Proline FMS. Now, they're not all finished, we realistically have weeks of work left given that we all have full time jobs, but...come on...if I can build functional FMS pages with less than two weeks of development experience, surely the professionals can do it. It took us a couple hours to add the ability to go direct to any arrival or approach fix. What kind of partnering, exactly, do they want? It's javascript, HTML and CSS. These are industry standard technologies that kids are learning in high school. In P3D/FSX I could have never done this - I don't know how to make a .GAU file. I don't know how to make a .DLL. I don't know how to make a .CAB file. But MSFS has made all that obsolete and introduced modern, simpler and easier to use technologies. Sure, some of the 3PDs want to port their .NET/C code over and for that, they need to use the WASM module I guess, but from personal hands-on experience, there's nothing stopping someone from building a GTN750 today that relies either on in-sim nav data or uses external nav data, like Navigraph.

Interesting. So, in theory, one could overhaul the G 3000, for example? What would be the first step in doing this? I know nothing about coding....

57 minutes ago, Ricardo41 said:

Kind of interesting that you have nothing to say about CWBurnett's post above, which basically blew your argument out the water.

Forgive me, but a whole lot of THAT going around.

 

11 hours ago, fppilot said:

Add on developers will suffer due to the MSFS shortcomings.  Is it just me?

 

I think just the opposite.  Addon devs will thrive due to the "lite" default aircraft in the sim.  Simmers are hungry for their systems-heavy addons.  3rd party devs will deliver!

Oh, also regarding weather - yeah it's totally screwed up, especially in the USA.  Asobo as acknowledged it in the new development update yesterday....I believe a patch is coming soon-ish

Edited September 4, 20205 yr by ryanbatcund

1 hour ago, fppilot said:

In real life I can tune GPS gauges in a fraction of the time it takes in this sim with the default gauges

I think it is worth pointing out that the reason I was motivated to work on this stuff is for exactly this reason. Your point is spot on and well taken as far as the current state of the default gauges. I was happy to see that Asobo acknowledged this in the Sep 3 update - specifically related to the G1000/G3000 being unfinished and needing work. They do.

1 hour ago, Ricardo41 said:

Interesting. So, in theory, one could overhaul the G 3000, for example? What would be the first step in doing this? I know nothing about coding....

Well, that was my question, also. I'm honestly not sure I can easily answer this question, since my solution has been to experiment, do some basic JavaScript reading/tutorials online and most importantly, find others that actually know these languages. Basically, start with an existing gauge and go for a small change to start. These changes can be incorporated into the sim without having to modify the core sim files. Instead, you can create copies of the files you want to modify and create a package for them in the Community folder. The SDK provides a tool for making packages, but there are also two easier-to-use tools to do this that are community-built. I outlined them in this thread:

The MSFS SDK Discord Server is also a really useful tool. The invite is in this thread (sorry, external link.... https://forums.flightsimulator.com/t/fsx-import-showcase/165910)

One of the guys I'm working with shared this guide with me from Coherent - it talks about how to optimize framerates and performance in this environment....pretty interesting stuff..

https://coherent-labs.com/Documentation/cpp-gt/d9/df1/performance_guide.html

Here's a great example of what can be done, though...just as a start:

This mod allows you to turn Synthetic Vision on and off, as well as control brightness in the G1000. Now, the G1000 appears to be high on Asobo's list to enhance, so we could see some improvements in the next month from them, but even if they don't step up, the community and third parties will...

9 hours ago, cwburnett said:

It took us a couple hours to add the ability to go direct to any arrival or approach fix.

Have you shared this?  It is one of the issues I have faced and would like to overcome it.