Mother child
-
Never quite understood how to setup the mother/child connection into a DC. Here is a model which has several DC components inside a group. What I am trying is to have separate control by clicking on the different parts. That is; I want the whole section to retract when clicking, -but at the same time the "Bottom Support to fold in. The plexi Covers are separate and opens/closes only when clicked on. Can anybody help me understand how to set it up. Attached is the model.
-
all onclick functions should on the same level of nesting otherwise the top will work in preference to the lower as its triggered first and shields the rest.
Combine two or more actions using semicolon between onclick functions, or use a common variablecheers
philipPS
had to fix the height reference to stop the overall shrinking to change in the bounding box as toe is withdrawn
change group to component as can not reference a group back to the parentthe base is the trigger for the slide
-
@pcmoor said:
all onclick functions should on the same level of nesting otherwise the top will work in preference to the lower as its triggered first and shields the rest.
Combine two or more actions using semicolon between onclick functions, or use a common variablecheers
philipPS
had to fix the height reference to stop the overall shrinking to change in the bounding box as toe is withdrawn
change group to component as can not reference a group back to the parentthe base is the trigger for the slide
Wow! Philip, thanks. Learnt something from this. Have to "chew" on it for some time to understand what you did though. What does size (LenZ) have to do with it?
-
Well, I didn´t quite get this. Here I have the same problem. This is a foldout bed where the foot should fold out at the same time and movement as the bed swings out. Can anybody help me out
[img][/img]
Here is the model: Loft160 Bed
-
could you upload a 2017 version? not intending to update this time.
generally each rotation needs to separate with its own nesting (world axis), however the example on https://forums.sketchup.com/t/rotating-more-than-one-axis-with-a-dc/54350 may work, but best to work your example
-
@pcmoor said:
could you upload a 2017 version? not intending to update this time.
generally each rotation needs to separate with its own nesting (world axis), however the example on https://forums.sketchup.com/t/rotating-more-than-one-axis-with-a-dc/54350 may work, but best to work your example
Thank you pcmoor. Christmas came between
Find attached the 2017 version
Thank you for helping and Merry Christmas in post
-
A Merry Christmas too
First
as foot is a child of bed, then need to choose either as onClick point, not both. The parent or the closest child "onclick" will always trigger before any lower nested "onClick"I made the bed a component, this fixes the size issues one has to account for if using groups and rotation.
If still want to use groups then you need to use a separate attribute to pass the value to the nested rotation and fix any sizes affected by the rotation.
attached two files, one using groups, other where I converted the group "bed" to a component
cheers for the new year
Philip
-
Thank you Philip for saving me once more.
I try to reason how this works but it doesn´t come easy to me. I have to work with it.
Thank you and may you and your family have a happy new year -
@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 simpleSo 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
Advertisement