Quote from WBard on May 9, 2012, 09:24
Also, have you reported the issue on the Aerosoft forums? As you have stated their product causes crashes in both FSX and P3D.
Short anwser "NO"
Like so many addon aircarft, this plane on initial release had "hidden issues" in Basic Multiplayer, and the same issues were also there in Free Flight, but less obvious.
Because of the Multiplayer issues, few users, if any, were able to use this plane in a Multiplayer session.
I have been working with the Aererosoft developers, to help them correct the Multiplayer issues (Typically looping Key-Events, causing UPD packet flooding ), and all these issues have benn corrected, as well as the developer know understanding how to avoid causing these loops in future product devlopment.
However, we are still left with a Gauge, that while it does not FLOOD UDP packets, and works currectly as expected in Free Flight, and Multiplayer, does have an issues with its initial syncronization of gauge variables, when it first joins a "Multiplayer Shared Cockpit" condition.
The CTD issue, seems to be associated with the Joining Aircraft, informing the Host aircarft, of its Gauge variables.
It seems to be caused by either a Gauge size, or a number of Variables issue, but by the time the CTD occurs in one of the Windows Libraries, it is not easy (posssible) for a user to really determine what has caused it.
There is nothing in the SDK that covers any such limitations, and I am therefore assuming it is some overlooked overflow condition, that was never expected to occur, back when FSX was in it infancy, and Planes and gauges were significanyly less complex.
Since this CTD event is 100% reproducable, and can occur, my initial post was to bring this to Lockheeds attention, and ask what else they required (from me), in order to look into this CTD issue.
It would appear to me the only way to quicky determine the cause, would be to reproduce the situation, while running in a debugger, and see what is really causing the problem to the Windows Library.
Or maybe just knowing the details that lead to the CTD, is enough for a quick visual scan of the Source Code, to indicate where the issue is being caused.
Without some investigation as to the cause, and hope fully a correction, those developing XML Gauges (and most likely C gauges, as it would appear to be some MP Shared Cockpiy overflow issue), are lest, not knowing what the limits are for their gauges, either w.r.t. Size, or Number of Variables.
That being said, I realize Lockheed has its priorities, which those outside are not privy to, so the only priorities that we see, as developers, are those we have, or see mentioned in the forum. (the subject for a different post !! )