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.
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)
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.
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!)
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.