Could we have something between Locked and Unlocked? Can copy, but not move

Both Scott Baker (@NewThinking2) and I have been having trouble in a complex model.

We want to be able to lock some existing parts of a big model, to prevent them moving by accident, but still need to be able to copy them.

We both frequently found, in spite of trying to be very careful, that things would move that we didn’t want to move after carefully placing them, but which we needed to copy elsewhere too.

If you have an unlocked component, with one or more locked sub component(s), you can still move the parent component and move its locked contents with it, though you can neither move them relative to each other or the parent, nor copy them individually.

But to be able to copy one of the subcomponents to another location, you have to unlock it too.

And then, particularly if it is nested a level or three down, it is fatally easy not to move far enough up the hierarchy before locking things again, and making a move.

In a smaller model, you could do this by dragging a new subcomponent out of the Component Browser.

But the component browser has many tens of thousands of components already, and the number is still growing. Just opening it takes tens of minutes on my machine, and still minutes on Scott’s faster iMac.

Neither the browser or the outliner are of any use in a model of this size, as SU completely slows to a halt if either is open.

Could there please be some additional status - for the moment, say, call if Freeze - which would allow you to copy a locked object, but not move it at all relative either to its parent, or to world axes?

I would even suggest to modify the locked state to keep an entity unmodifiable but allow copying. Copying is not modifying.
Maybe it was once intended that the “locked” feature also serves as a copy protection mechanism (copyright/DRM), but it clearly does not achieve that and it should not mix two different goals.

1 Like

Agree with both you and John on this. Copying is not modifying and SU should allow it even when a component is locked.

Also, I would add that I wish there was a component layer feature that would show at a glance which layers a component appears in. We are creating a model with each level (floor) as a separate layer, but there are 97 levels, so it’s hard to remember which ones had a particular wall, for example. I try to get around this by naming a wall for its level the first time, but that’s strictly my convention and not always a successful one. If there was a list of layers a selected component appears in, that would be very helpful, especially in a model which is now approaching 2,000 layers and nearly a million components (most of these, alas, are from over-designs of the 3DW downloads and we will clean some of this up, eventually).

I agree completely! Instead of adding an additional concept that users need to remember (and remember how it differs from locked), just fix locked to allow for copying.

A much better idea than having to have a new concept. Thanks, both of you.

1 Like

… and “Freeze” has a performance meaning in CAD, ie, it’s is a special state of “offness” where the objects are not loaded into memory.

So using this term would create confusion with persons moving back and forth between CAD and SU.

1 Like

I agree - bad choice of word. Sorry. Locked will do fine, if its meaning changes as suggested by others in this thread.

I’m going to open a feature request for allowing copying of locked entities.

1 Like

Thanks very much Mark. (@mchandler).

Would that mean that you could leave a set of nested components locked at one or more levels up to the top component, and select and copy some or all subcomponents? So nothing could move, but you could copy parts?

Though it would probably do what Scott and I wanted well enough if the top component were locked, to copy the lot, move it where you want, then unlock and delete anything you didn’t need to have copied.

It might be hard (it’s impossible at the moment) to allow selection of only some subcomponents inside a locked component.

Not sure how it’ll be implemented, but it’s been entered in our internal database.

That’s more than good enough for the moment. Thanks again, Mark.

To me the most logical behavior is that locking an instance locks that instance alone, not its parents, i.e. the current behavior. You lock something in relation to the local coordinate axes, but if the parent container is moved its internal axes and everything in it is moved with it.

It’s logical, and I’m not suggesting changing that. Just that when a component is locked, you could still copy it without unlocking it.

I must have been confused by your previous comment.

Sorry, it wasn’t very clearly worded, I agree in retrospect.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.