We are making a model based on a previously created model, a number of properties use formulas to refer to a parent and another group. When checking on a scene with a single component, everything is fine, as you can see in the screenshot.
As soon as the import on the scene, where there are other components - the formulas start to break. They generally take some old names that were changed a long time ago. Tried to use ruby snippet to uniqueize groups and components. But it didn’t help. All this can lead to the fact that when selecting the previously set properties, such as depth 30\60\90 cm, the model begins to take no specified dimensions at all. The scene is set in centimeters, in the properties it is rigidly specified that the values to take not default specified in the program, but centimeters.
One idea: Have you turned off “Display units format” (Window menu>Model Info>Units)? Metric Dynamic Components break down (convert to inches) if you uncheck the box.
with components jumping back to “old values” when placed with others, means that they have been updated outside the presence of components they were derived from. Using parent! instead of the named of the parent can help as far changing of the parent name in a formula. However complete changes means there exists a component that is not unique, usually the lowest level. Only way to fix this is build a file, adding one component at a time, then seeing if the number of components increase for each sub.
use the outliner and entity info, select each sub in the new dc placed in ffile and look for 2 or more in model
Do I understand correctly that you have to make a unique defination? The logic is as follows, and from the example itself.
This is a dynamic component and I need to make two pieces on the same scene. When copying, there is an automatic unique defination. And there is no such thing when importing.
The definition is attached to the working file, an instance of this definition is displayed.
Uniqueness is triggered when you insert a component and certain conditions apply, these are part of the code and can only be observed. Some I observe are…
Having different geometry, hence different source for a component with the same name.
A one level DC, no nesting, behaves as a normal component.
DCs with one or more nested DCs trigger uniqueness when one of its children change.
…
When you cannibalize a DC to make another, you must do it in presence of all the other DCs derived from this template, you need to make elements unique if there are to be formula changes. This apply especially to groups as they too link when copied. (there is an uniqueness script you can apply to groups).
If you rely on instance names in the DC, then you use the parent! rather than the “the specific name”! for referencing, so when you cannibalize these DCs they are not dependent on a specific parent name.
As an exercise, make a simple box DC, enter the component and make the geometry another DC, add formula to change its shape. Save as the parent to a folder, now change the nested formula and then saveas a different file. Open a new file and place them in to it, you will notice that because the definition being derived from the same, the first entered object overrules the other despite you renaming it. There is a conflict because they share the same “code name conditions, that we mere users cannot see”
