Well said, Paul, if this were my board that would be the last word.Ed GreenKCLThttp://www.panelshop.com/DEV.jpg

---

http://www.oncourse-software.co.uk/forum_images/fdc_beta.jpg

Hi, Jean.>As far as I remember also, some software that extend the features of word, also modify the normal.dot file

Yes I see the difference!Fortunately, with Word, as opposed to FS, you barely have the choice to change Word settings, thus it always load the normal.dot template before you can even load you own .doc files. Applying word initialization logic to the FS world, it would be as if starting FS automatically loads the default C172 @ KSEA, and only from then, you could load your other aircraft/reposition somewhere else.Nevertheless, some people are not happy loading a default aircraft at a default place, and this is the only thing that matters isn't it?Hope this helps!

Hi, Jean.My main problem with the way some people

>I thought that meant it wasn't necessary to load the default>flight first in that case. If not, what does it mean?>>Can you illustrate your point about a state variable that>cannot be set programmatically but that needs to be set to a>specific value and which, by implication, needs to be accessed>by a gauge for its correct operation?It means no more nor less than what was stated. SIMPLE gauges that rely only on stock FS variables do (mostly) do not require loading a default flight first.To which I'll add, that such SIMPLE aircraft and gauges may in fact BE the default flight!Yes, I could get very specific, but this is not the right venue for such a discussion, and quite frankly I'm not convinced that you'd accept the explanation. I've read enough of your messages now to convince me that you simply like to be confrontational, and are not truly interested in learning at all.If I'm wrong, then take it to the Aircraft & Panel forum where this belongs...

OK, the only Urban Legend I will deal with is that it takes a "complex" add-on to crash FS at load. I recently found that I had created a rather simple add-on which would crash the sim if it was loaded from the startup flight.The add-on consists of a module and a gauge. The module reads data from FSUIPC and passes it through to a bunch of user defined XML variables. It's been tested by a couple of experienced XML gauge programmers, and is rock solid. It reads data from the sim; it doesn't write anything back to it.The gauge was actually only created to test the module (by displaying data read from it,) but it was where the problem lay. Using a technique documented in the SDK, I created a shared variable in the module that the gauge could access. The gauge worked fine as long as it was not loaded from the startup flight. When it was loaded from the startup flight, it consistently generated a General Protection Fault. When I removed the reference to the module's shared variable, the gauge loaded fine from any flight. I then put the reference to the shared variable back in, but included a check for the variable's existence in front of the attempt to read to read from it. This technique also worked. The only possible conclusion is that at startup FS was loading gauges before it had loaded my module. I was a little surprised by this finding, even though I am sure nobody ever promised us that modules would be loaded first.Lesson for programmers - never presume that a shared variable will be present, even if you programmed it. Always check first.I'm not going to suggest that the situation I describe above is the only one that can lead to FS failing on load, but it clearly is one possible cause, so I thought it worth passing along.Doug

"Well said, Paul, if this were my board that would be the last word."Sound advice Ed...-John