Well, that would be impossible to do.  The same G1000 in the flight sim is used in turbine planes, single engine planes, twin- engine planes, and special adaptions such as the SR-22. Each one is different. 

Flying a flight sim on a desk with a monitor, keyboard and mouse will never, ever, be like setting in the pilot's seat of a real aircraft. I have never understood why some flight sim pilots (that probably are not real pilots) insist on restrictions such as popup windows, key bindings, and things that make flying in the sim easier.

Ray

35 minutes ago, raymar said:

Well, that would be impossible to do.  The same G1000 in the flight sim is used in turbine planes, single engine planes, twin- engine planes, and special adaptions such as the SR-22. Each one is different.

Oh, absolutely, I'm not arguing with that.   That variation is part of why we changed the engine panel to be extra-customizable, so we could better adapt to different planes.  But we're a small team with a huge task and we need to prioritize what we do.   Making things closer to reality is what the majority of users seek, so that's what we tend to first.   If we can add enhancements / quality of life improvements in a way that is optional and it doesn't take a lot of time away from the main goal I'm all for it.   To date that's been challenging to do give the realities of the way the G1000 is designed, but with the work that our main UI guy has been putting into a total revamp of the G1000 UI it's going to be a lot easier in the future.

11 hours ago, MattNischan said:

Actually, surprisingly similar. Not to spill the beans too much on what is to come for the various Working Title projects, but coming in the near to medium term are areas that could be considered to be entirely new instruments or systems totally from scratch.

First off, feel free to "spill the beans" about what you have in mind for upcoming projects. 😁

You mentioned "near to medium term" .  Is that (one week to one month) or (six months to two years)?

The reason I ask is because what your group is doing is just so cool that it does give us regular users something to look forward to in the future.  I'm sure part of any hesitation to spill beans of future projects and set timeframes is due to expectations being set and then criticism coming from the community when they don't pan out as expected but I promise I won't be one of those. 🤭

I know you probably still won't be willing to reply to the above questions, but this is something I would be very interested in knowing, just from an educational point of view.  When you get a request to add a feature or make a change, how do you know whether it is something that is easily doable within your scope or something that is NOT doable due to the application construction.  For instance, you were able to make a change to the MFD and show the map HEADING UP.  But the little airport depiction on the map is still rotated as original (north up).  Or, the PFD loads flight plans that come in from an external application, but to date, the MFD doesn't follow suit.  Are all of these issues fixable by your group, or are some of these issues only fixable by Asobo due to some deep internal compiled executable buried in the program?

Great job by the way!

1 hour ago, LarryD said:

I'm sure part of any hesitation to spill beans of future projects and set timeframes is due to expectations being set and then criticism coming from the community when they don't pan out as expected but I promise I won't be one of those.

Haha, yeah, that's definitely one of the concerns.   It's always risky to make any promises in development that can come back to haunt you. And it's not so much being coy as that there are still a number of unknowns that need to be sorted and it's hard to judge the impact those might have.   It's fairly safe to say you won't have anything this week, but I also don't think we're looking at anything close to 2 years.   I've been removed enough from the details of this particular effort that I don't want to get any more specific, but maybe Matt can if he continues to feel daring.

1 hour ago, LarryD said:

For instance, you were able to make a change to the MFD and show the map HEADING UP.  But the little airport depiction on the map is still rotated as original (north up).

That's fixed, or just about, and will be coming out with future updates to the G1000 and then other Garmin units that make a number of improvements to the map.

1 hour ago, LarryD said:

Are all of these issues fixable by your group, or are some of these issues only fixable by Asobo due to some deep internal compiled executable buried in the program?

It varies.  As a general guideline, time permitting, we can probably find a way to fix anything that doesn't involve either changes in the 3D model or the flight management and autopilot logic, and even then we can bodge some things on to fix some of the worst bits.  Problems that involve communication between units can probably be solved as well.   (We haven't used it for anything yet that I know of, but we have a prototype for an LVar-based data bus with surprising bandwidth.  It's insane, but it works, and it's a neat thing to have in the back pocket if we end up wanting to make things pass a lot of data around).

The worst bits of the flight management issues are baked into the sim, though, and we need to gut and replace that logic wholesale to fix it.

@kaosfere Do you know if this issue on doing a U-turn to the last waypoint when entering an approach mid-flight is supposedly fixed in the G1000 mod?

 

1 minute ago, Virtual-Chris said:

@kaosfere Do you know if this issue on doing a U-turn to the last waypoint when entering an approach mid-flight is supposedly fixed in the G1000 mod?

Yep, it does.    The GNS530 mod by pms50 does the same for that unit from what I read.

1 minute ago, kaosfere said:

Yep, it does.    The GNS530 mod by pms50 does the same for that unit from what I read.

I was flying with the mod last night and still running into this issue.  I'll double check it's loading, but the G1000 had my previous settings saved so it seemed to be loading. I wonder if it somehow got broken again... or I'm not doing something right?  What is a good way to confirm the mod is loaded?

Edited October 15, 20205 yr by Virtual-Chris

1 minute ago, Virtual-Chris said:

I was flying with the mod last night and still running into this issue.  I'll double check it's loading, but the G1000 had my previous settings saved so it seemed to be loading. I wonder if it somehow got broken again... or I'm not doing something right?  What is a good way to confirm the mod is loaded?

That's odd.  I can check to make sure there hasn't been a reversion.  If you can replicate it can you share a sample flight plan that doesn't work?   That fix was some of the earliest FMS improvement work we did, it might need to be enhanced or corrected in some way.

3 hours ago, Virtual-Chris said:

I think the focus should be on making it realistic.  Whatever width it is in real life, it should be in the sim.

I think what I'd say is what should be realistic to the extent reasonably possible is display readability and useability. The sim's VC 'environment' presents some challenges not present in the real cockpit although TrackIR helps with this to some extent, at least for me.

Al

Edited October 15, 20205 yr by ark

32 minutes ago, kaosfere said:

That's odd.  I can check to make sure there hasn't been a reversion.  If you can replicate it can you share a sample flight plan that doesn't work?   That fix was some of the earliest FMS improvement work we did, it might need to be enhanced or corrected in some way.

I've had instant U-turns on loading the assigned approach on 2 flights recently as well.

Flight plan with the last waypoint at the destination airport, waited for ATC to assign the approach, selected it and hit 'load', instant U-turn.

I'll toss some info into a github issue later tonight.  I have videos, if that helps.

On 10/14/2020 at 10:08 PM, himmelhorse said:

My impression is that both are still waiting for the SDK to be upgraded to the point where they can use it.

I'm not singling you out in quoting you, it is just recurring and illustrative of something I feel it is important to understand about what's going on.

I've been reading this discussion and among other things, it is raising the very same integration questions I've been dealing with for the last 2 decades working exclusively in building gauges and systems for the flight simulator franchise (FS8 to P3D5) and for the x-plane franchise (XP9 to XP11).

Our products are almost unique in the flight simulation world, not because they are based on the trainer, but because they must integrate with any aircraft so that the navigation data they're providing is working with the aircraft instrumentation. They are also unique because they must be retrofitted in any panel not just for the look, but for the user interaction. And this is not just clicking a knob with a mouse, but making any form of user input (mouse, keyboard, programmatically) seamlessly integrated in the user experience. This is also a unique position, compared to other 3rd party vendors building whole-aircraft, because it makes you thinking out the box and finding novel ways which seamlessly work for our customers.

What most customers are ignoring though, is achieving the high level of sophistication from a SDK gauge standpoint only (I'm not talking about the GPS simulation) is not something any FS SDK is providing the means to. We can build our products on X-Plane in using the X-Plane SDK as-is, whereas there is no other way to do them in any flight simulator product without augmenting and patching the internal code, because the SDK is exactly reflecting the very idea an add-on product is a self-contained entity, regardless of the other add-ons, and regardless many simmers are mixing add-ons together with overlapping functionality sometimes, and the very questions surfacing with inter-mods conflicts in this topic are also exposing the same mindset prevails among 3rd party developers, and why I feel compelled to explain why I believe it is not representing some of the challenges 3rd party developers are dealing with the SDK, and how this has nothing to do with embracing new technologies like JS/HTML.

One such example of how much the FS mindset is strong is in assuming any RXP GPS product in FS2020 would require the aircraft having a spot to place it. Thinking outside the box I'd say please consider this instead: make the SDK providing the means to instantiate a 3D model + texture + clickspots at runtime. Please note the facilities to instantiate a 3D model with its texture and clickspots is exactly what every simulator is already doing when loading your aircraft. The idea is just extending the very same asset loading and instancing capabilities so that an add-on could do the same once the aircraft is loaded, from data saved on disk or in memory. Adding a GPS add-on to any aircraft would be, at least for the visual/panel part of it (I want to keep the example simple enough) much more easy and supported by the SDK, and it would be sufficient with some aircraft where adding the GPS atop the existing one would effectively hide it underneath. Nevertheless, it would be better also having the SDK supporting altering the loaded 3D model at runtime so that add-ons could remove unnecessary parts.

The example above which consists in giving add-ons the capability to instantiate and remove model geometry at runtime, inherently calls for also having model introspection capabilities at runtime, which in turn opens a whole lot category of features any 3rd party add-on could benefit from. For example, instead of dealing with antiquated panel.cfg files for different panels, this could be handled at runtime as-is. Instead of having to build complex animations in a model to hide/show optional features, it could handled as-is. Instead of having to create custom L:Vars to "share" control points for the model animation, introspection would permit any add-on directly controlling this, etc...

This is a just a small illustration explaining some of my point of view you can often read in my posts, either explicitly or implicitly: by necessity to developing our products and finding solutions to the various integration needs, it gave me, I believe, a certain transversal perspective to some needs which are transcending some of the SDK concepts deeply rooted in its architecture right now. But the same needs for RXP are also orthogonal and useful for any 3rd party vendors. I also believe due to the unique nature of the R&D and work I've been doing for the last 20 years, and in doing so and working closely with ACE Studio and Laminar Research developers, I have also a certain overview of each ecosystem strengths in terms of gauge and systems SDK and how this could benefit the FS2020 platform.

Which leads me back to the quote above: I can assure you I'm not waiting for anything, quite the contrary. I've been proactive as much as possible raising awareness to these questions and forward thinking vision, helping my peer simmers in the FS2020 forum as much as I could, contacting MS and Asobo people to build a relationship and raising fundamental and practical questions but offering at the same time the directions they could follow to solve these, which most of the time are easy to implement on the existing infrastructure, and I'm still open pursuing the opportunity to sharing my knowledge and ideas to whomever is listening but willing to act.

 

 

Edited March 12, 20215 yr by RXP

Jean,

Thank you so very much for your post here. It explains a lot (most of which I do not understand) 

Given the "whomever is listening but willing to act" aspect, I would now assume most people will be wondering if this does indeed take place in the near future, how long will it take to get your product into our patiently waiting aircraft. 

I do appreciate that this is largely out of your hands but it really would be interesting to get some sort of time frame ie days, weeks, months or years.

Thanks again mate

Tony

17 minutes ago, RXP said:

Our products are almost unique in the flight simulation world, not because they are based on the trainer, but because they must integrate with any aircraft so that the navigation data they're providing is working with the aircraft instrumentation.

It would help me in understanding the issues that are being discussed, if the avionics integration (GPS/HSI/autopilot/Navdata/Flightplan) were discussed separately from the visual 3d panel integration... I am sure it all matters, but it can sound quite confusing if all these challenges are lumped together.. 😉