, Jr. Member
Let’s start with a caveat: I have not looked at the Away3D examples for over five years.
Yet, with the amplified information you provided concerning the lines of source code which correspond to the brief stack dump you posted, I am going to guess that you have architected your application around the Away3d examples which used functions named init() and initEngine() to get to the statement which raised the 1009 Error.
If you look at that statement, the reference which is null pretty assuredly has to be the reference your code holds to the singleton instance of the Flash runtime Stage. In all likelihood your Main class extends Sprite in order to gain access to the stage property shared by all DisplayObjects.
Let me pause right there. I am not writing this offer of help at this very basic level in any way to criticise, rather to suggest that you step back from the problem you are describing to think about the ways you might trouble-shoot the problem yourself. It appears to me that you have fallen into a trap I often fall into: If the methods and processes that you have been using to create a running piece of code fail, and one of the distinguishing attributes of your new attempt is working with a hitherto unfamiliar library or framework, it is somewhat natural to suspect that the new “stuff” is the cause of your problem.
Without the benefit of more information revealing your sources and even your build environments, it might not be possible for me to diagnose your problem, but by stepping back to your basic Flash skills, I suspect it will turn out that what you are seeing is the long-standing and correct behavior of the runtime—a behavior which you could reproduce with absolutely no Molehill [see, that’s how long it has been since I looked at this “stuff”], absolutely no Away3D code present in the test case at all.
Indeed, if I am correct about the problem you are experiencing, stepping back to basic Flashmanship would likely cause you to modify the code snippet you have probably copied from some earlier Away3d example. Look at the statement that fails. What is it trying to do? Does it really make much sense for a child, sub-application, loaded swf set of code to be modifying the overall state of the application as being rendered by the runtime? Wouldn’t the initialization of the parameters of the Stage normally be accomplished as a part of the initialization of the primary swf code execution?
I suspect if you just want to no-op the lines of code which attempt to set the parameters of the stage when the loaded swf is being executed, you’ll be able to continue on with your debugging/testing/enhancing work just fine. Otherwise, if you find good reason to attempt to set stage properties in the loaded sub-application, you can google the old Adobe documentation for Actionscript 3.0 and see good explanations/examples of when the value of the stage property can be relied upon and when it cannot. The short answer is that you need not only to wait on a complete event from the LoaderInfo object embedded in the Loader instance which I suppose you are using to load the sub-application, but you subsequently need to wait on an addedToStage event on the Loader instance itself, because, as a subclass of DisplayObject, Loader will only gain a valid reference to the stage when it is added directly, or more more likely indirectly, through some other DisplayObjectContainer which is part of your application architecture.
In summary, there is very little possibility that the source of your problem has anything directly to do with Away3d code and it would not matter in what directory structure you placed a swc containing that code no matter whether your IDE involves FlashDevelop or Adobe’s own toolchain.
I hope I have guessed right about your problem. If not, please provide any additional information that might be helpful, and good luck with getting your test to the next level.
