After a very cumbersome and long multi step process to select a bunch (over 11 K) of mesh faces I went ahead an run the command that I needed to run: Scale Positions, and the selection is gone. It turns out ScalePositions does not let me work with mesh faces.
New Rule: All transform commands should work with all object types, of all topology types, including sub-objects that are transformable. Can you please make sure someone at McNeel goes over all the transform tools and makes sure they are working in Nurbs, Meshes, SubD, and all its subobjects?
Hi @pascal, NameSelections is not my friend, yet. It will have to work a lot better to reach that point in our relationship. It actually has so many problems that I’m just going to ignore it for now.
Hi Gustavo - what would it have to do, to be allowed to share your working life? Not select as soon as you touch it? Not rename the set to the command you type right after calling up the selection? (Fixed! as of this morning) Those two are hard for me but we’re still friends…
-Pascal
Being able to overwrite named selection would be really good. Right now if I want to add to one, I can’t. I can’t even save something with the same name and have that cause an overwrite. It causes two named selections with the same name.
Also, it needs the arrows for moving items up and down, like the layers window has.
I’m very glad to hear about those things you fixed though. They were driving me nuts. I figured out how to deal with them, but I’m glad they’re gone.
@Max3 Why not make the save and delete the original? I’m not sure how adding the complexity of an Overwrite is more proficient here? Select > Save New > Delete whatever you no longer want?
For example, almost every time I am saving a named view, it is to the same name it already has, in order to overwrite. To the point I wish there was an overwrite button, so I wouldn’t have to confirm the overwrite.
I wish McNeel could have an internship program for their developers where 1 week a quarter they come to a client’s team (remote for now, office-based in the future) and they join the workload of the week and take part of what is like to work in a production environment.
I volunteer our company to be a pilot for this. Any McNeel developer is welcome to join for a week, a month, a summer. Even follow along a project or two remotely, in its entirety (typical design project is 2-4 months, full product development Is 6-18 months) via our online project management tool. So the can experience themselves what is like using Rhino in the real world.
I appreciate your dramatic flare and emotion on the subject, but this didnt seem like the end of the world. Saving is fast and simple. I can certainly add whatever the group consensus is. And hey, I am happy to share my model collection with ya any time
Yep. I’d follow the named views workflow, and add an explicit overwrite (probably called “update” not overwrite) button to both. If you are concerned about performing a destructive action without confirmation, undo/redo would probably be the usual solution for that.
@jdhill there has to be prompt or some warning. While undo/redo certainly works if you catch it right away the undo stack could be gone later so that’s not a dependable way out to rely on. I’ve had a Merge option in mind as well as an Update Selection. So it sounds your request will fit in with that. I likely will prompt to Update though.
I would not use the Rhino undo stack, it would be local to each item … “oops, I didn’t mean to update that item”. I am assuming the data is not very complex. But whatever, you get the point.
