geoffda

Old thread, but I'm encountering this very problem on Windows 11 and it looks like the issue has to do with MCE using the wrong paths for things. There are going to be two "Documents" folders for anyone using One Drive and syncing (as I am). One will be under \Users\<user name>\Documents and the other will be under \Users\<user name>\One Drive\Documents. In my case, the Multi Crew Experience folder is getting created under Users\One Drive\Documents, but Process Monitor shows that the Simbrief integration code in mce.exe is expecting it under \Users\<user name>\Documents. When it tries to create the .dat files, that fails because the path doesn't exist. If I manually create the Multi Crew Experience folder there, I get a bit farther--the .dat files get created, but then I'm stuck with "Waiting for Simbrief data". The dat files are being read, but for whatever reason, the flight plan isn't actually loaded. I suspect that there is a problem in the way MCE is obtaining paths to the Documents folder since the Simbrief integration is generating the local path, but the rest of the MCE code seems to use the One Drive path (which is probably a redirect).

Thanks for the clarifications. I will adjust accordingly.

Hi, I'm creating some custom checklists for the PMDG 737-800, but some things aren't working. Here are my first three checklists: _____________________________________________________________________________ Preflight [ ] Pilot, flight attendant briefings -- Complete [ ] ACARS -- Initialized, Connected [ ] Flight Deck Windows -- Closed, locked [ ] Oxygen -- Checked, set one hundred percent //3 [ ] IRS selectors -- Nav [ ] Pressurization -- Set, auto [ ] Auto throttles -- Armed [ ] Altimeters and flight instruments -- _ inches set //3 [ ] Speed brake lever -- Down detent [ ] Parking brake -- Set, pressure normal [ ] Engine start levers -- Cutoff [ ] M R D, gear pins -- Checked, onboard _____________________________________________________________________________ Before Push [ ] Seatbelt signs -- On [ ] Fuel -- Planned gate _ onboard [ ] Fuel pumps -- _ on, crossfeed closed [ ] Hydraulic pumps -- Checked, on [ ] Doors -- Closed _______________________________________________________________________ After Start [ ] Generators -- On [ ] Probe Heat -- On [ ] Anti-ice -- _ [ ] Recall -- Checked [ ] Autobrakes -- R T O [ ] Flight controls -- Checked In the case of the Preflight checklist, the first item is incorrectly read as "flight briefings." In the case of the Before Push checklist, once I reply to the "Fuel pumps" challenge with, say, "mains on, crossfeed closed," the FO then replies, "Now said Hydraulic pumps, doors, now said Before Push Checklist complete, now said." The FO never waits for a response to the last two challenges. In the case of After Start checklist, when I respond to "Anti-ice" with "off," I get "check that item again, would you?" even though anti-ice is off. If I say on, I get the same response, so it seems the FO is getting incorrect information. Is there some way to just preven the FO from trying to verify this as a workaround? Any idea why these behaviors are occuring? Thanks!

For anyone else encountering something like this, the Num Lock key needs to be on for the binds to work correctly for extended keys. In the case of the End key, when Num Lock is off, it gets treated as the Num Pad 1 key--which is the default MSFS bind for up elevator trim.

PM Sent.

Thanks. Unless there is something that got introduced by the specific Windows build I just upgraded to, there must be something going on that is local to my machine...Now that we have camera simvars, I'll try to sidestep whatever the problem is by using those.

Thanks, (and I just saw your edit, so thanks for saving me the the effort of trawling docs to figure out how to send the enum values 🙂 ). That seems to work. What is weird is that I just tried uninstalling/reinstalling and now the bind half-works. On the first button press, I get the external camera view (though it still moves the trim), but on the second press, it doesn't recognize the End press and only sends the trim up.

Yeah, I tried that as well. (FOCUS:FlightSimulator)·(VKD:79-207-35)·(SPLIT:100)·(VKU:79-207-35)·· has the exact same behavior; that is it results in an elevator trim up event.

I have a button bound to VK_END to trigger the external camera view in MSFS 2020. This has worked for ages (and in fact was working two days ago). Starting today, VK_END is now triggering elevator trim up instead of the external camera view. Pressing the End key on the keyboard results in the expected behavior. 1. If I delete the AAO binding, then the button press no longer triggers a trim up event, so that would suggest that I don't somehow have a trim up event bound to that button elsewhere. Nevertheless, I have verified that there is nothing else bound to that button in my MSFS settings. 2. Deleting the binding and recreating it results in the same behavior. 3. Starting with a brand new aircraft profile and creating the binding results in the same behavior. This is includes trying several different aircraft. 4. Binding to different buttons and/or different controllers results in the same behavior. 5. Binding VK:Insert instead of VK:End does not work. It appears to do nothing, but it is possible that it is triggering an incorrect bind that I'm just not aware of. 6. The same bind works correctly using FSUIPC. 7. Uninstalling and reinstalling AAO had no effect. 8. Renaming the LorbyAxisAndOhsMSFS directory and creating the bind in a new profile has no effect. 9. Using the scripting All signs point to this being an AAO problem. I'm running Windows 11 22H2 (OS Build 22621.2283) and I did pick up this update today, so it is possible that it introduced an issue. AFIK, that is the only thing that has changed on my machine since this was working two days ago. Can anybody confirm that the End key can be bound in this Windows 11 build for MSFS and that the binding correctly triggers the external camera view? Otherwise, if anybody has any further suggestions on what to try or how to debug this I'd appreciate it!

I purchased the Black Square Analog Baron and had the mixture levers on my Honeycomb Bravo Throttle Quadrant bound to the L:BKSQ_MixtureLeverPosition_1, Number (and _2) LVARS with an Axis min of 0 and and an Axis max of 100. This was working well, I believe, until I installed the v3.0 upgrade. When it was working, the 0-100 values were evenly distributed across the full range of the mixture lever movment. Now, the 0-100 range is exhausted by just a small movement of the lever. Is anybody else experiencing problems with axis min/max scaling?

v 1.4.3 Hotfix: 1. Regression: GT750Nxi does not shut down when avionics bus switch is off, nor does it shut down when the aircraft is completely powered down. 2. Regression: Magnetos shutoff bar doesn't animate backward (to shut off mags). 3. Old bug I think, but the EFB doesn't seem to charge. Often, after a long flight, it has a dead battery when I try to display it. Doesn't seem to be a way to power it back up when it gets in that state.

Anti-collision lights (strobes) are extremely difficult to see in daylight in v. 1.4.2.

A couple of bugs for the new v1.2.0 release: 1) Prop lever still has no effect on the RPM when on the ground. That is, trying to test the prop governors during engine run-up results in no RPM drop when pulling the prop levers back. 2) Fuel computer now counts down, but the fuel flow, while better, still appears to be too high. I tried 0.75 for the fuel_flow_scalar and that was just a bit low so I'm thinking somewhere around 0.85 is probably going to be dead on. I think someone else reported that 0.85 was pretty accurate.

I can confirm the fuel bugs. The fuel computer is somewhat broken and I experienced the inability to reset it after landing, shutting down and refueling. Fuel burn seems excessive. I had to stop and refuel to complete an ~800nm flight from KRNT to KSBP today at 65% power at FL220. According to the POH I should have had over 1100nm range and nearly 7 hours of endurance. Even with the headwinds I was fighting, the flight should have been an easy nonstop. Instead, I was going through fuel like I had a leak somewhere and ended up needing to refuel in KUKI which was ~600nm. Something seems to be not right...

Fuel flows seem way off... At 17,000 feet and -20 C with 31.5" MP and 24500 RPM, I'm getting fuel flows of 194 lbs/hr for each engine; i.e. nearly 400 lbs/hour burn. Looking at the performance tables, fuel flow should be about half that; i.e. ~200 lbs/hr. I forgot to check what I had left when I landed to see if the fuel gauges agreed with the fuel computer burn. Also, I filled tanks prior to starting and set the fuel computer to tanks topped. That showed 206 gallons of fuel remaining, but the number never decreased during the flight.