skiselkov

I'm afraid we do not support multi-machine flying in this manner. The slave machines are quite simply running independent copies of the plane, so naturally all of the systems in them are completely out of sync. We only support multi-monitor operation from a single sim instance, not multiple networked ones.

You need to set MODE to WEATHER or GROUND and actually point the radar at something (e.g. some precipitation, or the ground). I would recommend you give the avionics manual a read: https://static.garmin.com/pumac/190-00709-06_A.pdf You will want to take a look at section "6.3 AIRBORNE COLOR WEATHER RADAR". That explains what all the modes mean and how to control the radar.

Can you check if you can find the following file in your X-Plane install? Custom Scenery/Global Airports/Earth nav data/apt.dat This is the file that the frequencies are read from. Also check if you have any other scenery installed that might be covering said airports. The frequency loader uses your custom scenery load ordering and it catches the first occurrence of the airport. If the first occurrence is missing frequency information, it will be missing from the charts display as well. apt.dat files are actually text fiels, albeit somewhat large ones. Something like Notepad++ should be able to open them and search inside of them. When you open an apt.dat file, first look for a line that contains the airport identifier. The Global Airports apt.dat file should contain a line like: 1 604 1 0 KSTL St Louis Lambert Intl That means that lines following it are defining airport features for the St Louis airport. In the standard Global Airports apt.dat file, after the KSTL line, you should be able to find lines starting with values 1050 through 1056. Those lines define frequencies: 1050 125025 ATIS 1051 122950 UNICOM 1052 119500 CLNC DEL 1053 121900 ST LOUIS GND 1053 121650 ST LOUIS GND ...etc... If those are not there, or another instances of the KSTL airport is higher in the custom scenery load order (which lacks these lines), that will mean they won't appear in the charts display. Probably the easiest method to try and fix this is to temporarily move all custom scenery you added out of the "Custom Scenery" folder and backing up your scenery_packs.ini file (move it out of there as well). That will force X-Plane to re-generate the scenery packs INI file with just the stock custom scenery installed. If that helps, try looking inside your added custom scenery if you can find an apt.dat that defines another KSTL that might have over-ridden the stock one.

Strange. Just tested it on 11.34 and it works perfectly for me.

The issue is with using command_once. The avionics system needs to have the command activated for at least 1 full frame. However command_once immediately fires all 3 phases of the command (begin+continue+end). That means the CAS control logic never sees the button "depressed" during the flight loop callback. The fix is to call command_begin and then call command_end on the NEXT simulator frame.

What I suspect is happening with the rain is that it's overlaying the cursor (somehow) when the rain happens to lay between your viewpoint and the mouse cursor. I'll investigate to see if I can somehow coax the thing to work.

I've found the source of the issue. We had implemented a workaround for excessive amps draw in XP11.30 and later, however, this wasn't being applied in the wear model. So the wear model still though the alternator was being overloaded. Will be fixed in next update.

Which airports did you try? And can you send me your Log.txt when this happens? It should contain relevant diagnostic info.

I think there is a background task going on where the avionics is downloading the obstacle database from the FAA. It can take a couple of minutes, especially on slow connections. If you try to quit out of the airplane during that process (or when it attempts to do a reload as you hit Yes/No on that flight recovery screen), it needs to wait for that download to complete. Can you try giving it 5-10 minutes?

@Carsten Sorry to hear you are having trouble. The grey background is a "flight recovery" screen - it happens when the TBM detects that the sim crashed on the last run and lets you put the aircraft back to where it was to continue the flight. However, it should show a little Yes/No question dialog in the center of the screen. Are you by any chance running a multi-monitor setup? If so, there might be an issue that the dialog is being shown off-screen (if the screen layout is sufficiently complicated, it can have trouble figuring out where the "center" of the entire desktop is). A quick workaround would be to switch X-Plane temporarily into windowed mode, load up the TBM and pick "No" from the flight recovery dialog, and then switch it back into multi-monitor mode as you would normally want to use. If this helps, can you please also describe the way you have your screens set up? I can try implementing a fix in future versions so it properly detects your monitor setup and shows the window dialog on the main monitor.

Correct, this is not implemented ATM. I want to reimplement the entire TMR/REF page using custom code at some point, but that is not on the immediate agenda.

These are harmless. It's just the navaid parsing code complaining about some formatting errors in the navaid files, but these can be safely ignored. They have nothing whatsoever to do with any crashes you might have experienced.

You should use rudder trim to remove any sideslip (keep the slip indicator centered). With the yaw damper on, this is taken care of automatically. Any remaining rolling tendencies can be fixed by either small amounts of aileron trim, or by use of the yoke. All aircraft have inherent rolling tendencies, especially those with a single nose-mounted engine. There will be slight differential fuel and payload weight between left and right, random air currents, engine torque and aileron trim effectiveness changes with airspeed, etc. Don't assume that you can take your hands off the controls and have the aircraft remain flying perfectly straight indefinitely. This is not the case in the simulator, nor is it the case IRL.

This looks like some AV software acting up. NtProtectVirtualMemory is an internal NT kernel call and some AV software tends to hook into it to try and access process memory. In most cases that I've seen online, restarting the machine a couple of times helps. Alternatively, you can try disabling the AV software and seeing if that helps.

@sd_flyer Going to need some more context. How and when did this crash happen? Can it be reproduced? Have you tested without extra plugins loaded? Is it specific to a particular scenery?

Bug has been fixed, expect it in the next build.

Thanks for the report. I'll try to repro and fix this.

The landing gear warning is simply triggered by placing the throttle to idle.

Thanks for reporting this. I completely forgot we do custom rendering for all the arrows in the tutorial mode. I'll extend the renderer there to support VR as well, now that I know how to do it

While the battery test itself shouldn't reset the engine temps, performing maintenance does reset the engine temps. That's quite by design. Just not the battery test.

@cromsan Please always provide the Log.txt from the simulator when filing a support request. That message "connection failed, see log.txt" means we need to see what's in there!

I absolutely want to get this implemented, yes!

@dirkdej There are a couple of lights above the pilot's and copilot's head. The buttons are are a bit hard to see (they're unfortunately black on a black background) but that should give you a lot more ambient light in the cockpit.

@Shafs64 Did you check you have rain enabled in Plugins > TBM900 > Configure visual effects?

Please update your GPU driver. You are running a fairly old version and it has helped other users with such an old version before.