5 Replies Latest reply on Feb 9, 2018 8:28 PM by benl13565393

    Asset Sharing - Splitting up a big fla for easier teamwork




      (This contains:  A question for best practice + feedback and bug-reports for Author-time Sharing)


      I'm currently working in a game project with Flash Pro CC. It actually consists of multiple games (a handful) that all use one fla as asset-source. So it has mixed content, all game-specific assets + general assets (e.g. lots of re-used ui components).


      We are trying to split up the fla into one general fla and distinct game-specific flas (or "sub flas").

      The specific flas shall also contain the assets from general fla, but changes to the general fla shall also affect the lib items in the specific flas. And an auto-update is also needed (for convenience).


      So the target is 'importing a whole library' from one fla into another. Is there an "easy way" to do this?

      NOTE: the general source-fla with the files to share has a size of 35 Mb and contains about 600 symbols that are to share.



      Here are my efforts / experiences so far:


      On your help pages are communicated: Runtime Sharing and Author-time Sharing.

      I thought that the first one, Runtime Sharing, is no good choice, because it comes with bigger preparation effort (urls) + RSL-symbols have to be AS-linked also, which is not needed for much of our symbols. And then it seems to be focused rather on client's experience (e.g. loading times).


      So I tried out Author-time Sharing.


      First I noticed that one must manually declare the origin-target-relationship of each single symbol that shall be linked to a source file. (meaning to adjust properties and browse to sourcefile + symbol in its library).

      Is it a bug? In CS4 this was done automatically (simply on paste of a symbol of different fla). The whole workflow is so inconvenient that I have the feeling that a large-scale of this feature is not suggested. Or am I missing something?


      Anyway, I wrote a jsfl-script that takes care of that (for all wanted symbol items).

      It seemed to work well within a small test case (fla with 250 kb, 13 MovieClips, 7 images).


      But when I applied it to our project (35 Mb source file, 600 symbols) the script will not come to an end and Flash consumed increasingly more RAM.

      The duration of sharing just one symbol seemed to take over 10 seconds already.


      But there seemed to be also a bug that caused that some of the "want-to-be"-shared assets were not properly replaced, but instead created anew and were put into a directory "Duplicate items".

      After a little trying I found out, that this regularly happens to nested symbols, whereas these were not shared before that 'parent' symbol was shared. At least I guess so.



      As I found out there is an undeniable connection with source-file size and complexity of symbol structure.

      So, is this feature only recommended for slim source files with a few symbols of low complexity, meaning "no nested symbols"? (This would be a real pity for us.)


      Machine Details.

      Flash's Latest Updates are installed, Windows 8.1, 64 bit, CPU: 2 x 2.2 GHz, 8 Gb RAM


      Best Regards,


        • 1. Re: Asset Sharing - Splitting up a big fla for easier teamwork
          Mohanaraj Adobe Employee

          Hi Yves,

          I'm not sure whether this will be working for you or not but you may want to try.

          Create a folder named say 'rootfolder' in your Source.fla(all you need to make sure is that this folder name is unique w.r.t your target.fla library folders) and you can create a symbol named say 'root' inside the 'rootfolder'

          Drag drop all of your source.fla's library items (excluding rootfolder & root symbol) into root symbol's stage so as to pack your source symbols library items into a single symbol that you can link through Author-time Sharing

          Go back to your target file and create a new symbol and choose to link it to a 'root' symbol from your source.fla

          >>This way you can bring-in all of your source.fla's library items into your target.fla's library without getting into library conflicts as the linked items will be organized under rootlibrary folder


          In case if you face any issues please share the details along with the files for us to investigate. 




          • 2. Re: Asset Sharing - Splitting up a big fla for easier teamwork
            yvess86178491 Level 1

            Hello Mohan, thanks for your answer.


            I tried your way out, but unfortunately it did not work well for me, albeit it sounded very reasonable.


            1. When I put all assets to share into one root-clip and only share this one, the sub-assets lying on the root-clip's stage will not be updated in the target file unless you don't modify them in the "root"-clip of the source file (e.g. change position).


            2. If I modify the clip in the root-clip of the source file (and save), changes will indeed apply to the target file - that would be cool - but again it also produces the "Duplicate Items" folder and puts the recently modified sub-assets into that, while the old sub-assets are not replaced, but continue to exist (albeit not used anymore).


            Furthermore the updated sub asset (which now lies in "duplicate items" folder) seemed to have automatically received the correct author-time sharing properties at this point, and the auto-update flag was also set to true.

            This was not the case for the sub-assets when I first manually made the sharing-property-adjustments for the root clip (after I copied it into the target fla)


            Perhaps I'm doing something wrong here... this is exactly what I've done:

            -  I put all symbols I wanted to share into a root-clip

            - I copied the rootclip into the target fla (folder and name of the root clip still did not exist there)

            - I activate author-time sharing for that root-clip (in the target file, of course)


            Then every change I make in source fla should apply to target file. (after saving, and opening or switching to target document)

            That's not really the case (as described  above in 1. and 2.).


            I created a small-size example to reproduce that behavior:



            The tst_new_trg.fla was actually an empty fla which I wanted to import the lib to.

            As you can see, there is another folder "Ordner für doppelt vorhandene Elemente" which is the "Duplicate items" folder (in German version)




            • 3. Re: Asset Sharing - Splitting up a big fla for easier teamwork
              Mohanaraj Adobe Employee

              Hi Yves,

              I could sense this can only go wrong if you copy the rootclip from your source fla and paste it into your target fla. This is not required and will create a duplicate assets folder if you enable author time sharing for the rootclip. (this is because you have already manually copied all the lib items into the target fla by pasting the rootclip)

              Instead as I have mentioned in my earlier post, please create a new empty symbol in the target fla and link this to the rootclip from source fla via author time sharing.

              Hope this helps.




              • 4. Re: Asset Sharing - Splitting up a big fla for easier teamwork
                yvess86178491 Level 1

                Thank you, Mohan.


                Sorry for my late reply, I was a busy with other stuff the last days...


                To the topic:

                Yes it helped a lot already... I should have read better.

                It is a bit less intuiitive than I had expected, but this will work. The problem with the "duplicated items" folder is gone.


                However, I still wonder about how changes of the root clip (in origin file) take effect in the sharing files.

                I made some tests, and these are my observations, of how lib items are updated:



                • empty folders- not (of course, the are no symbols)
                • full folders - yes - originals remain as copy (with 0 uses in target-sharer)



                • moving and renaming in origin file is recognized in target file. however, "old" library items (as they were regarding their name and path) are retained, with 0 uses (if they were not used elseweir in the target file), and new lib items are created with the new names / pathes
                • But IF they are used elsewhere in target file (e.g. as instances lying on stage) their origin will not be updated, and in properties they still point to the original symbol with the names they had before moving / renaming (which is not existent in origin file anymore)
                • A not so good thing is, that if such symbols had an AS-link, they would exist twice in target file, both retaining their AS-link. So there is potential for conflicts...


                This behavior is still a bit inconvenient. One had to remove the deprecated symbols and (before that) swap the already-in-use symbols.


                I made 3 example files for you to reproduce what I have encountered.

                1 origin file, and 2 target files, which contain some remaining library items, that should have been deleted / swapped.

                In case of the 2nd target file, the rootclip lies in folder with different name. (though I have observed no difference in their behavior)




                And again the question: Am I doing something wrong? Or is there a way one can avoid this?

                (Changes to the source file, like renaming and moving, will be definitively needed!)




                • 5. Re: Asset Sharing - Splitting up a big fla for easier teamwork
                  benl13565393 Level 1

                  This is an old post, but thought I'd add some comments there. I've noticed the same thing here. That nested symbols and using JSFL to update shared files results in Duplicate Symbols. Just guessing that the problem lies with how names of symbols are encoded (folder + symbol name). There is no means (from what I can tell) of what file the symbol belongs to. So it seems that Animate essentially just decides its better to create a new duplicate symbol. More or less this feature seems like an afterthought because it is very painful to use unless you intervene via alternate means (see below).


                  I have found a solution, albeit a painful one. However, if you have large files, manually doing things is error prone.


                  Essentially you want to convert your FLA to an XFL. You then want to have scripts which go through the LIBRARY and force change the attributes within the XML that represent each symbol.


                  The attributes you want to permute are






                  Yep, it sounds gross, because it is gross.

                  But wait, it gets worse. You need to contend with relative directory issues. I've found the best way to do this is to have the shared file and the FLA that is referencing the shared file be in the same directory.


                  This means, when you convert to XFL, you need to put the shared FLA info the XFL directory. This is because (at least I'm my case), I'm using Animate to cover the XFL back to FLA. This means I have to open the XFL in Animate. But since everything is "relative", you unfortunately need the shared FLA in the XFL directory.


                  Although thinking about it now, I may take a new approach of re-tarring the XFL to a FLA to see if that works (I'm using tar to create the XFL).


                  Realistically, the shared files methodology really probably needs to better implementation.