Open JRiad opened 2 years ago
@andosca @Marco-Pellegrino what do you think?
Having a fixed identifier was discussed in #81 and is planned for implementation. So having the possibility to lock the identifier on the component level will be done.
Problem with export from FEM-Design should be raised to BP dev. team.
Duplicate of #81
Having a fixed identifier was discussed in #81 and is planned for implementation. So having the possibility to lock the identifier on the component level will be done.
Problem with export from FEM-Design should be raised to BP dev. team.
👍 Great! I saw it was discussed in #81 but I thought it is better to have a dedicated case for each topic 😉 On what components will this be implemented? Or is there going to be a new component for this?
It will be implemented on any component that creates or modifies an element (bar, slab, support etc.)
It will be implemented on any component that creates or modifies an element (bar, slab, support etc.)
Why not have this operation (of adding a single "@"/locking the identifier) as a separate component? Like below. element
could be of type EntityBase
or IStructuralElement
I think there might be cases were you want to lock the identifier without modifying the element.
Having a fixed identifier was discussed in #81 and is planned for implementation. So having the possibility to lock the identifier on the component level will be done. Problem with export from FEM-Design should be raised to BP dev. team.
👍 Great! I saw it was discussed in #81 but I thought it is better to have a dedicated case for each topic 😉 On what components will this be implemented? Or is there going to be a new component for this?
Maybe you are correct. I figured that they were so tightly related.
@xRadne That is also an option. Would possibly make for more components. As we intend to have a constructor/modifier for each type of element why not have it on that one as well?
@xRadne That is also an option. Would possibly make for more components. As we intend to have a constructor/modifier for each type of element why not have it on that one as well?
I suggest we do not add any extra input to the components (they have plenty of inputs already),
But instead the identifiers can be locked using a @
in the beginning (which will be equivalent to the .struxml
).
We should also add a grasshopper component that locks/unlocks the identifier of any element. This will be more intuitive to most users that don't know how the .struxml
works.
using @
at the beginning of the Identifier is a good option.
I am not a big fan of "large components" with several input and a custom component might be better from my point of view
using
@
at the beginning of the Identifier is a good option.I am not a big fan of "large components" with several input and a custom component might be better from my point of view
Just to be clear, Adding @
in the beginning is already working. But, I think it is unintuitive for beginners, and if you want to modify (lock/unlock) then it is needed to 1 deconstruct, 2 add @
, 3 modify bar/slab/panel/edgeconnection etc with new identifier
Hi! We have had some struggles lately with objects being re-numbered. For example, if the walls in a model are called W1, W2, W3.... they will sometimes be called the same thing when the struxml file is opened in FEM-Design again, but sometimes they will be renumbered.
To stop this from happening, we can put "@" before the slabpart name in the struxml. Then the numbering will be "locked".
It is also possible to lock the numbering in the FEM-Design UI, but this setting disappears when exporting to struxml.
We think it should be possible for the user to choose if they want renumbering or not. When renumbering is good: For example if you want to merge two models, or create a lot of objects and not want to handle potential conflicts between elements with the same name. When renumbering is bad: When you want to keep track of certain objects.
I'm not sure how this best could be implemented. Some ideas:
This has also been mentioned in case #81