Until the core code is changed [if ever!], then what you want is a script which does two things.
If one component-instance is selected the context-menu includes an item “Save As Xxxxx.skp”…
Where “Xxxxx” is the name of that instance’s definition [or as near to it as can be - e.g. a|:/<> etc are not allowed in file names but they are acceptable in a definition name !]
When you choose that item a dialog opens to choose the location folder [defaulting to your Components folder]…
A File menu addition “Save All Definitions into a Collection”…
When you choose that item a dialog opens to choose the location folder [defaulting to your Components folder]…
All definitions are saved with the name of that definition + .skp [or as near to it as can be - e.g. a|:/<> etc are not allowed in file names but they are acceptable in a definition name !]
Yes, thank you, it is very close to how I imagine it!
Yes, that would be nice, although in that case I can change the name of each file myself. Of course, this is time consuming, but not tragic.
It is possible that it can also be created as an additional command in the File menu, but I would prefer this command to be in the Components dialog instead of the “Save as local collection” command that is not working properly. Or, in the worst case, next to it, as “Save definitions as local collection”. Of course, the question arises as to what the “Save as local collection” command really does, because the result obtained by it is not always fully understood by the users, and uses component characteristics that the user does not actually use and does not even know about their existence.
P.S. I never use special character definitions in names. The exception is the comma, which in my country is the decimal separator. In this case, however, the program replaces it with an underscore, which is perfectly acceptable to me.
Here’s a simple script that does what you want.
Put the RB file into your Plugins folder and restart SketchUp…
It is not an extension and it’s not signed…
Usage: There are 2 tools…
a. Select one instance of a definition in your model to see the entry, then get…
Context-menu > Save_As… Definition ‘Xxxx.skp’ [where Xxxx is the name of the selected instance’s definition]
b. File menu || Context-menu > Save All Definitions into a Collection…
There is a file-counter displayed in the directory-selector header and the status-bar.
The directory-selector always defaults to the user’s Components folder, as set in Preferences…
Perhaps you could purge unused definitions first, then save-to-collection, then do an undo to undo purge if you want to keep the unused ones ?
The saving-out does nothing to the model itself…
Thanks, Mike, for linking me to this thread. As I’m just now learning how to save collections, I’m having all sorts of problems including over half the components not saving, and seeing name changes. Following…
I still consider this to be a bug, especially created by the developers. As an ordinary user, I do not need to know the nuances of programming or database architecture, that is not my business, but be able to get a logical and predictable result with the tools given to me. However, in this situation, the developers may have solved some of their own problems, but created unwanted problems for me as a user. This is not good practice.
I have worked with various databases and my experience in this case says:
if the definition names of different components within a single file cannot be non-unique, then they are sufficient component uniqueness identifiers. Why create another parallel system that is not accessible and usable by users, especially if it allows for duplication of identifiers and generates situations where information is lost (overwritten files)?
Hi All, I know this topic has been going for a while but here is a summary as I understand it:
When you create a New component using the ‘Make Unique’ command on a component that has a ‘Loaded From’ address (found in Edit tab in Components window) these problems start -
It retains the Old ‘Loaded From’ address (not helpful!)
If you then right click on this new component and ‘Save As’ the Old name shown is often displayed in the ‘Save As window’, so you have to correct this manually.
Some times when you import this component into another document it comes in with its OLD name. Not very useful; where is this OLD name located? (see below)
As a work-around, after I create a new Component using ‘Make Unique’ method; I make changes as required, then ‘Save As’, giving it the correct name I gave it after ‘Make Unique’ was used. This corrects the ‘Loaded From’ address.
Stopping it from being imported with its OLD name was the next problem! The Old name must be stored somewhere? I found it in the Model Info / File window, under ‘Name’! All I do is DELETE this name and don’t replace it! It then imports with its correct file name.
So a couple of Big question arise from this:
1 - Why is the ‘Loaded From’ address retained when you create a new component via ‘Make Unique’ command? This should have been removed when you ‘Make Unique’ it’s now a Internal Component.
2 - what is the ‘Name’ entry in Model Info / File used for? You you can delete it as I have done because its incorrect or when it’s correct (I tried that as well!) with no adverse affects on the file.
3 - Why is the components old/original name not replaced with the new name in the Model Info / File window?
Yes, it is part of this global issue. Quite often you also have to change the name of the component in the work process. The consequences are the same as creating a unique component. But the most incomprehensible is that it doesn’t always happen, but only SOMETIMES! When working on a large project, there is no time to pay special attention to possible mismatch of component names in the later storage process. Here, two levels of the program are mixed together: one that I don’t need to know as a user because I don’t use it at all (but is probably necessary for some program activities that I’m not interested in as a user), and the other that should be logical for users.
For example, this model contains 4502 instances of 623 unique components. During its development, I had to think not only about its construction, but also about the choice of materials, the order in which it will be built and disassemble on the stage with a minimum of staff in a short time, in what parts it needs to be divided so that it can be safely loaded into a sea container and elevators with limited dimensions, how to move it within NYC with smaller trucks and many other conditions, rather than wasting time “tricky” renaming components in a model.
@TIG
Unfortunately, the second part of the script (Save All Definitions into a Collection…) does not always work. I have noticed that this happens in large projects with many nested components. Is it possible that the script is limited by the number of components or the depth of nesting?
Could you explain what happens…
Run it with the Ruby Console open - any errors…
If you get a list of definition names how does that compare with the exported subfolder’s list ?
Use this in the Ruby Console to see what the list should be…
defns=Sketchup.active_model.definitions.each{|defn|
next if defn.image? || defn.group?
puts defn.name.gsub(/[\x00\/\\:\*\?\"<>\|#,]/, "_")
}
Do the definition names given by my snippet in the RC match those in the exported subfolder ?
By ‘incorrect names’ what do you mean e.g. XXX#1 becomes XXX_1, because # is best avoided in SKP file names…
What are the names of the ‘lost’ ones ?
At the moment if you have a definition named XXX#1 and another named XXX_1 they’ll both become XXX_ due to the ‘safe-naming’ tool…
As much info as you can give will help fix theis…
However I can sidestep that…
I’ll look into publishing an update shortly…
TIG-DefnSaver.rb (3.7 KB)
This v1.1 checks for existing SKPs in a collection subfolder and increments the end of the name to avoid overwriting…
So if you have definitions named XXX#1 and XXX_1 previously they’d both get SKPs named XXX_1.skp and so the later one would overwrite the older one, with v1.1 if XXX#1 is saved as XXX_1.skp now when it’s the turn of XXX_1 it’s renamed XXX_2.skp to avoid the overwriting issue…
This clash of exported names can be avoided by using definitions naming so that if the SKP’s name is ‘fixed’, e.g. to replace a : or # with _ - then duplicated SKPs are never produced when making a collection…
