subdivision party

[TECNOMODEL]

I am still here to ask for some suggestions to try to understand how the logic of this software works.
premise: I am working for a client who wants the job done with his software (modeling precisely) and set as he is accustomed.
he works with all the details under one group that is that of the whole equipment. I find it dispersed, I lose a lot of time to go looking for the various pieces in the tree whenever I want to turn on/spegnere, share.copy etc.
I then set the work using groups, and with your suggestions I found a good method that allows me, in the end, to take the various details inside the groups, to move them to the main group and to delete the group "fittizio" I had created.

All right, I've got some business problems.
the customer has a database with the various commercials (vitates,dades,spines,blocks etc) saved in .pkg that we go to load in the pkg of the project.
he told me as a first indication once a commercial of "make a copy, delete the imported one and rename it if not the software messs up."

now, for example, I load the dado m8 that has name dado_m8 and I insert it in a group.I share it, so I have dado_m8.1,dado_m8.2 etc.

I reload the same dice again from the database and put it in a second group, then I will again have a situation similar to the first group, dado_m8, dado_m8.1 etc.

I've finished the job, I have to bring all the components into the main group and they're pains. conflicts of names with particular names p1,p2 etc., double groups of the same particular dado_m8 and dado_m8.1.1 etc.

What I ask myself is how does a software that does not cost little, indeed, to not manage a trivial thing like this.
possible that all the management of the number of details is "leaved" to the name of the same ones that are freely editable?

Can someone explain to me the logic of the sharing system?

Thank you very much.

.

 

[Kaji]

the customer has a database with the various commercials (vitates,dades,spines,blocks etc) saved in .pkg that we go to load in the pkg of the project.
he told me as a first indication once a commercial of "make a copy, delete the imported one and rename it if not the software messs up."

personally I think it is better to select directly to video instead of looking in the tree structure, moreover a good compromise between fictitious groups and parts all at the same level could be transform the subparts to carry etc into a group faces; as you see in the image then the individual "groups" of the pattern (in the image I explore the pattern structure) can modify and manage them independently or through the change pattern commands move them all together.

the video below explains how to create a mixed group of parts and faces to manage as patterns.[video=youtube;SdmSzfKkcsI]https://www.youtube.com/watch?v=sdmszfkkcsi[/video]tools-rename-object

if then the main problem is the management of the name in the tree structure I think the command
tools-rename-object
automatically rename all parts and shared groups, even if in theory once saved to database the parts should appear in the structure tree with their database model name and not the name that changes time to time in the structure tree; with regard to the counting of the parties alongside each grouping of shared parties puts a number in brackets that represents how many shared parts there are within the group.

the logic of sharing is simply that two shared objects have the same id and are in fact the same object that appears several times in different positions, instead when you copy the two objects have different ids and are independent, so if you change one of the two the other remains as it was before, in particular I did not understand why to copy the library objects before taking them to the group, if assigning the library object remains equal it is necessary to be shared, otherwise when you save it in the new code.