I am modeling 3 different size tables with black pipe for legs and cross supports for a client. The black iron is joined by tee’s and elbows (models downloaded from McMaster Carr and revised). I have blocked the tees and elbows separately. When I select the blocks on one table and move them, the blocks on the other tables also move. I’m not editing the block definition in any way - I’m just moving 4 of them to a new position. Why would all the blocks in the model move in tandem?
Sorry if the answer is obvious and I’m just being ‘block headed’ but I’m under pressure for a deadline.
Thanks for the reply. That makes sense. I haven’t set any child / parent relations but I’m not clear about Record History - when it’s used, when not. So maybe I turned something on by mistake.
Hi Arial- . If History is involved, then when the extra objects move, the command line will report the number of objects updated. If it is involved (History) and you do not want it, then running HistoryPurge on the incorrectly moving items should sort it out. If the Record History pane is always Bold in the status bar, then History is being recorded for all eligible commands- generally not a good thing- right click on RecordHistory and un-check ‘Always record history’.
Thanks Pascal. Yes, that was it. Somehow History got set to Always and Update Children. Turning those off solved the issue. Client is happy, I’m happy. All is good.
Hi Arial- I think I would leave Update Children on, and remove history from objects that do not require it (HistoryPurge), Otherwise, you may at some point turn on History for a command and think it is broken due to the Update Children being un-checked. Normally (default, safe, behavior) is that History recording is off, and you click in the pane to turn it on for one command at a time i.e. you only get history if you explicitly ask for it per command.
Pascal and Arail, I think it is a worthwhile goal, both as an individual user and for Rhino 6, to make running with Always Record History the default behavior. It requires an adaption in thinking, IE, instead of moving an extrusion move the creation curve and let the extrusion follow, but the results make for powerful updating of the model. Selectively purging history is part of that thinking. One of the best features of Rhino history is that it is saved in the file, and will carry forward with SaveAs. Last week I opened an old file, point-edited a single curve, which updated 80 curves that had been created by Orient On Surface with copy option, which updated 40 One Rail Sweeps using the adjusted curves as profile curves. The key to making this possible was knowing that the next step, capping the sweeps, would break the history, so I had copied them and capped the copies, leaving the originals intact for future modifications. As Rhino continues to add history enabling to more commands (like Cap, and–this is really big I know–Fillet), it will be possible to carry these types of update even further. Blocks themselves are a kind of history, so if you’re used to updating blocks the step to recording all history is natural.
Hi Mark- you are welcome to set Always Record History in the Record History pane context menu , it will then be your default behavior. But keep in mind that if you do this, odd things may happen- copies of objects, perhaps hidden or out of view, will be changed if the original is changed and you will not know it until later- that is the main risk, I think- , and your file size may be quite a bit larger as well.