Reality check
Hi Tom,
I am afraid this thread seems to be yet another example of virtual pilot / flight engineer = consumer error being misrepresented as developer error in FS forums, but as always the question fails to provide all the information needed to accurately diagnose the consumer error. I must therefore take a stab in the dark and guess that you failed to set the condition lever for each relevant engine to 1%, only then starting it by opening the cover over the individual starting button below with your mouse?
Of course when Alphasim released this product back in 2003 they could have done much more to explain what the FS consumer is required to do to achieve operating compliance, instead of assuming that all FS consumers have real P&WC PT6A turbine ratings, but they did not fail to provide the necessary gauges, even though back then they made no attempt to include operable 'condition levers' in the 3D VC. To perform a 'somewhat realistic start' in the Alphasim Belfast the FS consumer must open and use the 2D pop up 'throttle' panel.
For reasons that relate to the real operation of the Rolls Royce Tyne, versus the P&WC PT6A engine, which is the only turboprop engine the MSFS hard code really simulates, Alphasim chose to code MIXTURE levers faked as CONDition levers. During what is always a P&WC PT6A start up inside MSFS the 'condition levers' still need to be operated compliantly by the FS consumer *even if the consumer imposes AUTOMIXTURE in the realism screen*. In the Alphasim Belfast they can be set to 1% using the consumer assigned keyboard MIXTURE controls, or by careful mouse drag *even if the consumer imposes AUTOMIXTURE in the realism screen*.
Like the freeware 'gauge cheat code' at Calclassic, (which may in some cases instead require automixture = false), the Alphasim payware 'gauge cheat code' will then 'take over and automate' the 'rate of increase of condition'. It isn't missing, but it is imperfect because it is from 2003, and most third party products in MSFS are better coded now than they were in 2003.
However, like most such misrepresentations in forums, the 'problem' has nothing to do with flight dynamics, and cannot be fixed by meddling with flight dynamics. The issue is whether gauge code is present, whether gauge code is working well, and whether the consumer understands how to use that gauge (code) compliantly. The whole FS community really do need to stop believing that the only code that can be missing, or broken, or inappropriately used, or never used, by the consumer, is FD code.
The 2003 Alphasim gauge code could be improved. The auto advance to 40% 'condition' is both too far, and too fast, but nobody is going to fix imperfect 2003 gauge code by meddling with flight dynamics, because the reported problem is not false simulation output from the FD at 1% or 40% of anything. The problem is consumer failure to impose 1% 'condition', followed by ancient gauge (cheat) code imposition of 40% 'condition' too soon. Once we open our minds to the idea that gauges also control simulation output, we can watch this 'too soon' auto advance of the 'condition', via the 'condition lever' gauge code, happening.
Of course what have been described as freeware and payware 'cheats' in this thread are just cleverly authored gauge code that attempts to deliver engine specific realism Microsoft omitted from the retail product. I am afraid the price of enhanced functional simulation realism is always increased complexity of operating compliance, that the FS consumer must master. The reality is that many FS consumers hate functional realism and the burden of learning multiple concurrent input compliances that it imposes upon them.
Many forum menbers, not just 'FD gurus', have been around the FS forums long enough to remember all the FS consumers back in 2003 complaining that the default King Air engines turned too fast, produced too much thrust, and that the default King Air would not slow down on the ground. Then always insisting that it must be an FD error. All sorts of silly meddling with FD was proposed across many forums. The reality was identical. FS consumers were simply unaware of the need to locate and use the P&WC PT6A condition levers, because Microsoft failed to provide adequate operating instructions and left it to the freeware community to explain how to use MSFS. Eleven years on that problem still persists, yet the community still has difficulty recognising it, each time it is misreported as FD error.
Most of these threads proposing that FD errors exist, really need to start with the statement. Here is *exactly* what I did. It did not work. Followed by the question 'What am I doing wrong'?
Why is it so hard to understand that the numbers consumers point needles at on gauges control the simulation output, and that consumers routinely point the needles at random numbers, but still expect to see compliant and realistic output? Non compliant consumer input is by far the most common cause of output errors of all kinds during desk top flight simulation. Both the questions asked, and the answers given in this forum need to take much greater account of that harsh reality.
FSAviator.
