Urban myth...

[Guest _FSAviator_]

Mgh has suggested that my earlier post; "doesn't explain why, if the sequence is open Flight Simulator and then create a new flight, it becomes necessary to load the default flight."That is because my post explained and illustrated that the requirement does not relate to the opening of Flight Simulator in any way at all, and why. However it is true that no one has illustrated the problems caused by use of the create flight menu. I will try to illustrate that in this post even though I regard it as a red herring.This thread will serve no useful purpose if readers do not grasp that the requirement is to control the environmental status that the aircraft and systems to be used during the flight first invoke within. That is why I chose to use accumulated ice and not something to do with an aircraft system status as the example in my illustration.Nevertheless as Bill has explained some 'complex aircraft' have systems that must invoke in a default state within the default environment and only then be adjusted to a non default state. This may include the requirement to invoke within a default density altitude (environment) before adjusting to a non default density altitude.The developer must not deliver gauge code or other code to force every status to default status overriding the content of any saved.FLT because the developer must deliver systems that are compatible with the possibility of

[Guest Vorlin]

I'm just chuckling a little bit because I think we were saying almost the same thing, but you added that not only is there an issue going from simple to complex AC, there can also be an issue going from one AC to another as in the issue of the cowl flaps.As one who has had to load provided baseline flights a lot, I understood your point above very well and I agree with you 100%. However, the order things were presented in may lead to confusion for someone who hasn't had to do this. Therefore, let me present a small amount of your post in a slightly different order for clarity:"The only procedure that will work all of the time is;1) Invoke the default flight environmentTHEN2) Invoke the actual aircraft to be usedTHEN3) Invoke the actual flight environment to be usedUnless the developer mandates use of a specific baseline.FLT environment instead." (In which case, the baseline.FLT is the ONLY way to make sure that you're properly set up to start a flight.)We often start the baseline flight, move the AC to another part of the world and then re-save as another flight name without ever starting the engines so that the AC state is preserved as much as possible in the new location. This works well most of the time, but I agree that it does pose some small risk. But the main point of this entire thread seems to be that some people think it's ok to swap straight from one AC to another... and the fact is that this patently false because it's NOT a good idea. We all do it from time to time but many of us know that there is always a chance that it's a move that will blow up in our faces. It is not a myth, it's a simple fact of life when dealing with computers and saved variables.Saved variables from a saved non-default or non-baseling flight are just as liable to mess things up as the saved variables in memory if you swap AC in mid-air. It has nothing to do with aircraft of aircraft developers and everything to do with computers and how they save / retrieve information.Scott / Vorlin

[n4gix 4,947]

Indeed... ;)My summary of the entire discussion to date is far less prosaic, but at least has the virtue of being succinct:"In short then, using a known-to-be-valid FLTSIM.FLT file is an excellent diagnostic tool, and - in 99.9% of the cases - proves to be the "cure" to user's issues." I would add also to the preceeding, "...never mind the reasons why this it true; simply accept that it is." :-wave

[Guest Vorlin]

Bill, I've never been one to drink the Kool-aid! LOLScott

[mgh 89]

"...never mind the reasons why this it true; simply accept that it is." End of story.