Namespace not found compile error

[Ralph B]

Just wondering if someone will take a look at the issue I posted on
Googlecode a while ago (ID no. 11). The problem is preventing me from
using any rev of Away3D since SVN 584, such as the very cool
PathExtrude class. If more info is needed or if I can help with this
please let me know. I banged my head until it hurt but am not smart
enough to figure out why Away3D would fight with CS3 Components at
compile time...
Thanks!!!
Ralph

[Jensa]

Hi Ralph,
I've seen similar problems before when working with components and
this one intrigued me enough to solve it.

Here is a FLA that confirms your bug:
http://www.flashgamer.com/a/bug11_test.fla

Here is a FLA that provides a solution to your bug:
http://www.flashgamer.com/a/bug11_fix.fla

In this FLA you can find a Compiled Symbol that ensures that all
classes are present when you compile. This is essentially now a
component that you cannot edit, but just drop this into and FLA and
you won't see any such errors again (hopefully...).

I made this by using this FLA:
http://www.flashgamer.com/a/away3dClasses_export.fla

combined with this class-file:
http://www.flashgamer.com/a/Away3dClasses.as

In the FLA, I have a Movieclip that is set to use the "Away3dClasses"
class. This class contains imports for the entire class hierarchy and
when you right click this symbol and say Convert to Compiled clip,
it'll stuff all linked classes into that symbol.

I hope this will solve your problem?

If there only was a proper MXI-file creator around, I could even turn
this into a component so that designers could just drag the symbol
onto stage instead of fiddling with classpaths?

J

[Jensa]

> component that you cannot edit, but just drop this into and FLA and

Ehh... I meant to write "drop this into your FLA"... :)

J

[Ralph B]

Hello Jensa,
Excellent, thank you! Your recreation of the bug also fails on my
machine, and your fixed FLA works. I will confirm it on one of my own
FLA's later.

Not sure I understand how your fix works, though. Given that I am not
a deep AS3 expert, can you explain a little bit about why your fix
works?

Thanks again!
Ralph

[Jensa]

Sure Ralph,
The problem here is that the Flash IDE isn't fully capable of
resolving all the classpaths. I really don't know why, but it happens
on occasions. This problem does not exist in Flex, FDT or FlashDevelop
as these all work differently.

The fix is to do just as you do for components. You create a clip that
contains the entire Away3D codebase. By doing this, Flash does not
need to import the classes (using the classpath) since all the code is
already present. The thing about components is that these rely on
external .as files and classes. The average user does not know how to
use classes, so back when components arrived, Macromedia created this
method to pack everything inside a "Compiled Clip".

The Compiled Clip is technically just a movieclip that contains a
bunch of code so that all the end user needs to do is to drop an
instance of this on stage (or just keep it in the library) and then
Flash wil use this definition of the class when creating the SWF.

The cool thing about this is that if somebody added the width and
height properties to View3D (and used this for clipping), I could for
instance make an Away3D component, just as there is for Papervision3D.
Just drag this component on stage, scale it and then set some
properties and even designers can show a 3D model without programming.
They can then of course also use this component to program against
since this contains the default View as well as all the required code
to make more complex stuff.

Did I manage to explain it properly?

J

[Ralph B]

Jens,
Well, I sort of follow your explanation, but let me make some
statements and tell me if they are true to see if I understand how to
use the fix:

1. The SWF in the library contains a snapshot of all the Away3D
classes (e.g. at SVN revision 630 when you made it).
2. Therefore there should be no need to include the Away3D source code
in the classpath in the Flash publish settings (but this can't be true
because it spits "not found" errors when I tried it. So what then is
Flash using for Away3D classes - the SWF or the classpath?)
3. The SWF just needs to sit in the library, and does not need to be
dragged onto the stage.
4. If I want to use a newer version of Away3D, I should ensure that
the classpath in away3dClasses_export.fla points to the desired Away3D
code base, then recompile to make a new SWF, which then needs to be
imported into the library of any functional FLA .

Can you give me a true/false for each of these?

Thanks!
Ralph

[Jensa]

Sure.

> 1. The SWF in the library contains a snapshot of all the Away3D
> classes (e.g. at SVN revision 630 when you made it).

true

> 2. Therefore there should be no need to include the Away3D source code
> in the classpath in the Flash publish settings (but this can't be true
> because it spits "not found" errors when I tried it.  So what then is
> Flash using for Away3D classes - the SWF or the classpath?)

I noticed this and it puzzled me a little. In theory, it should only
use the code inside the Compiled Clip. It does however look like any
class not used in the file that imports the Away3D classes (http://
www.flashgamer.com/a/Away3dClasses.as ) will not be included and thus
throws an error. This means that the Flash compiler insists on
removing every class not referenced. I've done a couple tests that
seem to confirm this.

Will have to do some thinking/digging around this one and come back to
you.

> 3. The SWF just needs to sit in the library, and does not need to be
> dragged onto the stage.

true

> 4. If I want to use a newer version of Away3D, I should ensure that
> the classpath in away3dClasses_export.fla points to the desired Away3D
> code base, then recompile to make a new SWF, which then needs to be
> imported into the library of any functional FLA .

False. You should not need to set the classpath at all. If you want a
newer version, you'll need an updated version of the Compiled Clip
(that holds the new code).

J

[Jensa]

OK
I've found a solution now. Try this FLA:
http://www.flashgamer.com/a/bug11_fix2.fla

The Complied Clip now contains the entire Away3D codebase. The
drawback is that this increases the file size with about 170Kb since
every class is there though not necessarily used.

J

[Ralph B]

Hi Jens, that worked great in both your test FLA and my problem
application, with the classpath to the Away3D folder removed and the
compiled SWF in the library instead.

Question: what is the procedure for building a fresh new compiled
Away3D classes SWF from scratch?

Thanks again!
Ralph

[Jensa]

Sure:
1. Make an AS3 class that references every class in the tree:
http://www.flashgamer.com/a/Away3dClasses.as

2. Make a FLA with a symbol that is set to export these classes:
http://www.flashgamer.com/a/away3dClasses_export.fla

3. Right click that symbol and select "Convert to Compiled Clip".

This compiled clip will now contain the codebase, so just drag it into
any FLA and you're ready.

This time, I did wrote Away3dClasses.as manually. If I'm ever to do it
again, I'll make an AIR applications that parses the entire Away3D
code-tree and writes the class. There's a constant flow of new classes
and functions in Away3D so to make sure it's always updated, it's
better to automate the creation of this file.

J

[Li]

Im not sure if this is related, but you can use flex to create an away3d library SWC.

Simply choose "New Flex Library Project", then paste away3d and nochump folders into the project, right click it and check both folders in the Classes tab of Flex Library Build Path. This automatically creates the swc that you can copy paste to some place in your disk.

If you want more detailed instructions check out this link: http://blog.paranoidferret.com/index.php/2008/03/28/getting-started-with-adobe-flex-and-away3d/

[Jensa]

Yup. Same thing but this is a little simpler.

You could create a SWC component and then distribute that instead. For
SWC's to work, you need to copy them to the proper folder and then
restart Flash Authoring. If done this way, the Flash compiler could
use only the classes referenced, resulting in a smaller SWF file.

Creating components sucks though. It's become gradually more complex
with every release. Adobe now has a 140 page guide for something that
used to take 30 minutes. Not only that - the guide is loaded with
errors and omissions. I've emailed them corrections to some of the
chapters, but I don't think they even cared to update :(

J

[Christian]

Did you make this application? I would love to have it because I am
running into this problem.