Not quite sure what is the problem, you could private message some examples; however some points

Breaking a bond is done by making the copied components unique. for groups, sometimes make unique (right click menu) is available.
If groups are the problem then running this script should help

http://ruby.sketchup.com/Sketchup/Group.html#make_unique-instance_method

Capture.jpg

If the copied groups or components have the same parent, same header then double click the title box to change its name before changing the attributes

Been busy and just saw your reply. Thanks for the help pcmoor!

More than one year after the last reply. I am assuming no one found a solution?

I just started using dynamic components and I was starting to be happy of the possibilities they allow, but now I came across the same problem you guys have (it's what lead me to this thread).

It is very frustrating that I cannot seem to identify a rule as to why and when SketchUp decides to make a unique component. For example I have a pipe and users can input the lenght. The component works perfect, no renaming no unique copies, no problems.. no matter what kind of copy/move operation I do.

Now I designed a component a bit more complex. It includes 3 groups and one sub-component. The position of that sub-component plus the size of the groups change according to what the user chooses (drop-down list)

If I just insert the component and move it/copy it NO new instances are created. But If I go to attributes and select the second configuration, right after I press APPLY, a new instance is created #1. Now, copying this new component does not create a #2, BUT if I dare to change one of these copies back to the first configuration, it creates a new instance.

This really ruins the whole purpose of having dynamic components....

At least if we had control over the renaming, for example appending at the end of the initial name, the label of the attribute changed.

it's just what I was looking for!
thank you!

Your main issue here is that you have the wheels changing direction by "mirroring" the cluster/row (of 3 wheels) across it's origin by using a negative length and sliding it over (offsetting). While clever, the wheels' positions aren't fixed, so they seem like they're getting it when they really don't know where to be. There may be a way to effectively use negative length for a component (I avoid it), but I'd suggest keeping it simple while you better your grasp the nuances of DCs.

Simplest solution: Add your position to each wheel (or set 1 with 2 copies) and add RotZ=parent!divert_direction. For the wheel group, add a Divert_Direction attribute (=parent!Divert_Direction) so you now have a pass-through attribute from the model to the wheels.

You'll probably also have to modify your position X if/then statement to account for the removed negative length formula

@pbacot said:

I don't know if this works in your setup or dynamic components for that matter. And I suspect it is no good if you are outputing the chosen material (color) in some bill of materials... But I use
"Material Replacer" to globally change a material in a model.

Thanks for the hint; I'm sure it is very usefull, but at the moment I suspect to have a serious performancies issue, for which I will post right now in a new topic.
Giacomo

I set mine to shortcut to the "`" key (above Tab)

Thanks!

Thank you tig i ll take a look at this and come back to you when i find the solution.

If I recall correctly, SketchUp Pro has a dynamic component of a bed that comes with it (crafted by SketchUp), maybe see if you can find this and poke around there a little.

Ah, I see! Thank you for explaining!

Cheers
Mikar

Thank you SJS66 i'll take a look at it.

Oui pilou j'ai vu ca 😉 c'est a l'étude 😎

open the component, select the raw geometry and make another component, set its axis in the direction you require, close
the nested component that holds the geometry is the one you will rotate. If you want to rotate in another direction as well, then you would nest it again so that the rotations are independent

I think I figured it out. Seems to be working now.

Oups sorry, I didn't check your references ...

Thanks.

@unknownuser said:

I try to reason how this works but it doesn't come easy to me.

It isn't easy. there are a few bugs to get your head around.
Perhaps it's helpful to understand that the dynamic part is a ruby script add on, it's not hard wired and as such has to work within the limitations of the ruby language and the developer's understanding when it was conceived. There are disconnections between what an attribute reports and the updated SU view, for example changing the rotation attribute will cancel out a previous input in any one of the others. Rotations involving groups can affect the size, the change seems to follow the changing boundary box.
Components seem to be more stable, but again misbehave when more than one axis is considered,

Despite the updates in Ruby there seems to be little done to fix these bugs, however there are workarounds to achieve the results you require.

The first important point, I would like you accept is that all onclicks need to be on the same level of nesting, there's no point placing an onclick event in a lower nesting than the other.

I generally use nested groups only for parts of an object, like an "I beam" made of top flange, web and bottom flange. Then the object (I beam), the sum of its parts, is then a component. Collections of components may be then held in a group.
So the second is that using dynamic groups can be more problematic, unless they are simple

So any animated object(s) should be a component and it is better to nest animated component(s) within another component, otherwise the rotation formula can be overridden when swapped or inserted.

At this point you may need to understand why attributes can be overridden, if they were not, then swapping a mouse with a elephant would mean their sizes would always match, etc. However you can match them, if the values are passed one level down and "current" is used in the parent if you want to, say have beam lengths to always match after a swap.

I am still trying to rationalise DCs intricacies myself. so most times I plug in data / methods until it works

Anyway, feel free to add any more problems, then can add some more observations

a bit of junk, sorry can be deleted, can't recall why I started it.....sign of age?

@chris fullmer said:

I went ahead and made a DC that does what you want. The user can choose one of 4 colors from a list. Then upon OnClick'ing on the component, it changes between dark, medium, and light of that color. I'll attach the DC and you can check it out.

Chris

Not only is he a fellow surfer with a cool hat, he's a sketchup legend. Love ya work mate!
Been searching for how to change materials by onclick all day. Doin' my head in.

Keep on paddling 😎

Are there any similar uses for the ";" that we may not know?

It is now many years, later, the current version is SketchUp 2017, yet I'm still seeing the exact same issue with a complex dynamic component.

The basic problem is that there are no global attributes in Dynamic Components: only local attributes that can be seen one level up and one level down in the hierarchy. I thought that this severe limitation could be bypassed by creating some lower level attributes the refer up to "parent!" attributes at a higher level, and others at higher levels that refer down to "child" attributes at lower levels, but it does not work. SketchUp does not traverse the entire hierarchy in both directions with each refresh or "redraw": it only seems to go down each branch once, so lower level attributes cannot be passed up one branch and down another.

Thus, the ONLY option is what the original poster already discovered, years ago: calculate all attributes at the highest level, and then pass them down each branch. There's no way to reliably pass things back up again, nor to pass things between branches of the hierarchy. It's a great pity, as adding the simple functionality of global attributes would solve the problem entirely, and completely avoid the need to be passing things around between levels!

Hopefully one day the SketchUp developers will figure out how to implement global attributes. Is this product even still being developed? There doesn't appear to have been any changes or updates to it at all, in YEARS! I have seen changes to the version number each year, but precious little in the way of new features, or even bug fixes. Is this a dead product?

In the meantime, your solution is the only way that works.