Would you go into more detail on exactly what you mean please? I currently have 3 WT packages installed
Garmin G1000 NXi version 0.14.0 OneStore
Garmin G1000 NXi version 1.1.0 OneStore
G3000 version 0.7.7 Community folder
I’m going to wait until the bruhaha subsides on the WTGNS530
Do I need both G1000’s installed? Should I uninstall any of them?
Is the G3000 going to be upgraded to be a Marketplace product?
I don’t know where to go to find information on all this, the G1000 is not discussed on the GitHub documentation page, and it’s not discussed as too which packages need to be installed in the first post here (or anywhere else that I’ve found so far in my searches, other than your statement).
Version 0.14.0 takes up a tiny amount of memory and simply redirects to 1.1.0 should any 3rd party mod still needs that redirect to function, so I would leave all 3 installed if you ever use the G1000 or the G3000.
Yeah, I’m not at all concerned about disk space. I just wasn’t sure which are still needed, and also wondering if they interfere with any other mods, too.
Interesting. Yeah, I’m not a big beta tester. I barely have time to use the sim at all, much less all the work beta testing takes.
So, does that mean their GitHub is defunct? It says 0.7.7 is the latest there…
So many sites and versions of everything to keep track of. And if you miss a post, bam, you’re lost in terms of being able to keep up…
Well, as soon as AAU 1 leaves Beta, at least all the Working Title updates will be driven by the Marketplace pushes so you’ll automatically get them all. They may keep GitHub for reporting, but I can’t imagine them keeping it for pushes.
I have the latest G1000 installed from the marketplace. I was watching this video and noticed this guy had a few things in the MFD that I didn’t have. When he changes the heading, there is a line on the MFD showing the heading line. There is also a line that shows the turning of the plane and a half circle showing where the plane will reach the desired altitude. Anyone know how I can enable those? I fly the Carvan if that makes a difference.
For the most part, the G1000 acts just as the real world unit. So if you do a search for G1000 manuals, or documentation you’ll be able to get around within the box more easily and get it doing what you want. Its not totally 1 for 1, but its getting really close.
I’ll be honest that without getting into the sim right now and digging I don’t remember exactly where those settings are, but from the map screen on the MFD if you rotate the knob on the lower right, you’ll find a number of settings pages in there that you can shuffle through using the smaller inner stacked knob and the push feature on that knob to select.
Depending on the screen you’re on, the menu button on the right side of the unit may also have some of the options you’re trying to find.
Hi @Sharpe2603
I think the options you’re looking for can be found by pushing the “menu” button, which will show you the box for “map settings”. Press “ent” button to get the map options, and then use the large FMS rotary dial to move between options, and the small FMS rotary to change the option once it’s highlighted. I think you’re looking for “track vector” and “Select ALT arc” options, and then turn those both on. The heading vector line will turn into an arc when you’re turning.
Regards
I’m having an issue where if I sometimes (can’t isolate when it happens) engage the VS mode while in AP mode, the plane will immediately dive down or pitch up 60-/+ degrees with the FPM indicator showing it to be set at something crazy like +2250 or -2250. Other times, it correctly defaults to zero until I select the rate of climb or descent using the Nose Up/Down dial. Anyone else getting this?
So… I think I may have isolated the problem. As you can see from the video, as soon as I engage VS Mode to descend, the plane takes a dive as you can see from the stick pushing forward (I had my hands off the yoke).
I use a Brunner force-feedback yoke, so since I did not touch the yoke when it took a dive, I assume it has something to do with the interaction between trim, FFB and the AP.
I’m wondering if others using FFB have this issue.
I asked this same question on the WT Discord g1000-nxi channel and will ask it here too in case someone who knows the answer does not use that Discord channel.
Is the Garmin 1000 NXI supposed to show traffic injected by FSLTL that uses SimConnect? 2 airliners were cleared to land ahead of me by ATC and I could see them in the sky/runway, but their position and altitude relative to me were not in the Garmin 1000 NXI, what I am used to seeing using built-in FS2020 live traffic. I have saved an FSLTL Injector log file that shows each airliner’s entries from injection through shut down at the gate, but before opening a support ticket with FSLTL, I wondered if showing FSLTL injected planes is not supported by the NXI maps.
I fly the Diamond DA62X mod.
UPDATE:
and for those who do not use Discord, the link in that post
I see other traffic around the airport (new KOAK mod in this case) and every departure as it becomes airborne, so that post correlates with what I am seeing in the FSLTL log, that both of these planes I could not see in the G1000 were injected airborne.
I can confirm that what you are reporting is as experienced by myself and others and it has been commented on several times in this topic. Hopefully the issue will eventually be fixed by the developers.
In my case I use AIG to inject AI traffic but I believe the problem affects FSLTL and any other third party addon that injects AI traffic using simconnect.
Pepperoni’s linked question contains the following observation: “Any AI aircraft that are generated airborne do not get returned with the GET_AIR_TRAFFIC Coherent call. Only aircraft that initially load in on the ground get returned, and are still returned when they are airborne.”
I wonder if a workaround that AIG and FSLTL could do for this issue would be for the injectors to initially inject these airplanes on the ground at the departure airport already specified in their Flight Tracker data, and then for the injector to enter some instruction that would slew each one to the location and altitude where they are injecting them now.
Do you know if this was ever tried by the injector developers and either did not work or consumed too many CPU resources to be practical?