JGregory

It's a moot point with regard to 1.5.1. I guess we will find out if your expectations were right or wrong when the update gets released.

We do not use the prop data out values as you think we do. I really don't have any more time to keep going back-and-forth about this... The question still remains... 1.If you disconnect your hardware, can you consistently reproduce the scenario where you get a failed auto-start? If not, then your assumptions are not correct and the problem is hardware related. and... 2. You should also consider that we are not getting any other complaints or bug reports about this and you are not the only user of the Saab that is using hardware to control the condition levers. Based on these two points the problem would be more than likely isolated to your system (hardware) and not a Saab related issue. But again, I think this is all a moot point as we will not be patching v1.51 anyway and the new update is not that far off.

Huh? What constitutes the "end" of a failed start to you ? If the starter is still running then I would not consider it the "end" of a failed start. And... once the starter is running it will only stop running at a pre-determined N1 (or loss of elect power), not the position off the Condition Lever. Are you certain about that ? Have you observed the joystick Datarefs to see what happens to them when you disco your hardware? It's possible that the act of disconnecting itself introduces a temporary noise/spike.. who knows! I don't think you should assume it doesn't. It's not quite that simple. I used the term "noise" as one example of a potential problem. The bigger picture was that your hardware was not behaving in some manner and that was causing the engine start failure. We are simply taking the values from your hardware (assigned as Prop) as an input of the condition levers (position). If the failed start ONLY happens when you have hardware connected then that tells me the hardware is causing a problem. I have no way of knowing exactly what that problem is since I don't have your hardware. it's starting to feel like you may be over analyzing this. And, we are basically "beating a dead horse" here anyway. The next update is not that far off and all of the manipulator logic has been re-written, including the Power Levers and Condition Levers. So, even if we found an issue that is currently affecting v1.51 we would not be issuing a patch for it anyway.

I'm fairly sure that our code does not take into consideration the user disconnecting their hardware in the middle of an engine start, so I'm not surprised by what you've found. Not sure an aircraft reload is necessary. Have you tried to power off the entire aircraft after a failed start?

Anthony, It sounds like you've discovered the problem. At this point I think it's safe to say the aircraft is performing as expected. Your logic regarding the condition levers being tied into the battery temp logic is not correct. You can test this by using the GPU for your starts and continuing to use your hardware for the condition levers...this eliminates the battery temp restriction on multiple starts. My guess is that you will continue to have the same failed starts because, as you have discovered, the issue appears to be in your hardware (noise) mapped to the condition levers. Without reading the code, I believe that if our engine logic does not find the condition levers in the "START" detent then you may get failed starts (probably due to fuel starvation), especially if the CL is below the START detent. Cleaning the hardware may eliminate some of the noise. In addition, you may try re-calibrating the hardware in X-Plane.

Right, "hardware", as in yokes, throttles, pedals, etc. You mentioned in one of your posts that you had the condition levers "mapped" to your throttle quadrant. As an example, the last log you sent shows you have something mapped to prop and mixture. You need to disconnect ALL your hardware to do a proper test. BTW.. when doing tests with plugins, it is not enough to just "disable" a plugin, you need to remove it from the plugins folder entirely. I see that you mentioned you had a test copy of XP where only Gizmo was installed... that's the correct way to test. Does that mean there were instances where the engine did start ??

You system is running several plugins, has a fair amount of custom scenery with plugins, and you are using hardware. The easiest way to START diagnosing this is to either remove the plugins and hardware, or download the X-Plane demo, and then try the autostart. If that works then you will need to determine which plugin or hardware is conflicting.

The OP stated he was having issues with Auto-Start. You are doing a manual start and did not even mention if you tried Auto-Start.

Yes. Update: I should clarify this. We will not be releasing production versions of the Saab that "require" the experimental flight model. Austin will always be adding things to the experimental flight model and we may not be aware of them or have tested with them. So, due to the potential instability of the experimental flight model we will not recommend (nor support) you use it with the Saab, but that is your choice. Of course, when the features in the experimental flight model get moved into the base sim we will test and release updates as necessary.

Please be more specific. Was the Tool Tray Menu working previously? When you move the cursor to the upper right of your display, does the menu not appear? Is the Saab activated? We need more details. FYI... just "disabling" plugins does not guarantee no conflicts. If you suspect a plugin conflict you should temporarily remove all extra plugins and then load the Saab and test.

Definitely not in this update. We will evaluate for v2.0 (need to see some real world examples to justify).

The same thing happened with X-Enviro, only crashed with the Saab. At first they said it wasn't their problem but eventually they admitted it was and they fixed it. If the Saab was causing the crash then we should see something in the logs, but there is nothing there... only the reference to Traffic Global. Traffic Global is a relatively new product so it would not be surprising for it to have some "bugs". The Saab has been on the market for years without causing CTDs. Are you pushing the tiller wheel down ?? That activates the steering. You no longer need to assign the CL in that manner. Simply assign your hardware to Prop1 and Prop2.

The last (4). four lines of the Log.txt file are... TGXP: Crash TGXP: Exception in thread 9520d: (null) TGXP: - Arg 1 : 0x0000000000000000 TGXP: - Arg 2 : 0xFFFFFFFFFFFFFFFF That is Traffic Global crashing the sim, not the Saab. Suggest you remove that plugin and/or contact the developer.

Post your Log.txt and GizmoLog.txt files.

YES !!! YES!!! Very Soon™

Steve, You have a lot of plugins and I'll bet one of them is causing this problem. Suggest you remove all plugins and see if that solves the problem. Then put them back one at a time and test till you find the plugin that is causing the issue. When you do find it I suggest you contact the author and let them know that there plugin is conflicting with the Saab.

Steve, Pleas post your Log.txt and GizmoLog.txt files.

The Dataref unit of measure for the temperature is in Fahrenheit. The Dataref unit of measure for the torque is in Newton Meters. These values are keyframed in Blender to produce the correct gauge readings. There are no Datarefs that have the Celsius or % Torque values.

You can use these for now, they will be changing in v2.0.... LES/saab/engine_torque_L LES/saab/engine_torque_R LES/saab/engine_temp_L LES/saab/engine_temp_R

I'm sorry Steve, I can't see any "yellow rays" in that picture. And, when you say "in front of the cockpit" are you talking about inside the aircraft? or outside?

Can you be a little more specific? That picture I very dark and I cannot assume what you think the problem is.

Since you posted in the Saab forums can I assume you want the Saab Datarefs? Or, do you want X-Plane Datarefs?

That's programming 101. I can assure you that Laminar, LES, and Maxx-XP are all seasoned enough to know to NOT divide by zero and check the value prior to doing the division.

The problem is that your log files are not indicating anything with regard to the crash. Instead of having you remove all your scenery and remove all your plugins, it would be easier to just install the demo and test. That way we can start with a clean slate and, if it still crashes with SkyMaxx we know exactly where the problem is. Otherwise there are just too many combinations to debug. Without that test I don't really have any other suggestions. Of course anything is possible, but just reading and writing datarefs should not cause a CTD. The Saab and SkyMaxx could write to the same dataref and cause erroneous behavior but a CTD is not likely. I'm not sure exactly what you mean by "validating" a dataref before using it. You are certainly not the only customer who is using these two products in conjunction with each other, so the problem is not likely as simple as a "clash" between the two.

Besides having a lot of plugins, you have a lot of custom scenery as well. I would suggest you download the X-Plane demo as a clean install, then install the Saab and test, Ifr all is OK, add SkyMaxx and test again. Let us know what you find. Also, are you running in VR mode ?