Hi @erfajo - I looked briefly at the implementation:
I think that the node naming of the node is not aligned with the revit API/UI and instead was intended to be simpler to understand for new users - but I agree it seems to only add confusion since internally this node creates shared parameters using a shared parameter file.
I think in this case the group is used just as a way of avoiding collisions between parameters in the shared parameter file with the same name.
I defer to the community or Revit teams usually on Revit API functionality though. If you think we should get rid of this input, we can obsolete this node and change it in 3.0.
FYI: I needed a Project Parameter that comes from the Shared Parameter file, as I need to be able to Schedule as well as Tag the element. As I understand it this is the only Parameter Type that can be Scheduled as well as be able to be used in a Tag. Isn’t this correct?
In our company we share the shared parameters (protocol) as a file with our project partners such as construction and the MEP guys aswell. Consistancy is key in some projects.
This allows us to create filters that work for all, and in all models, for instance.
It’s part of our collaboration strategy and it is working very well.
If you could make me a node that would give me the value of a parameter by parameterGUID it would make me very happy.
Maybe i didn’t explain very well.
We have cases where we end up with double, triple or many Shared Project parameters with the same name.
Only one of those is the original shared parameter from the shared parameter file with its GUID.
Imagine we have a Dynamo workflow where we use SetParameterByName and i use that name of the multiple parameter.
Where does the data go?
People tend to copy from linked files bringing in the parameters aswell, and people tend to create parameters that are already in the project evironment when creating families (you can only know when you were aware of that). We have Reviteers with little experience and full blown masters.
Lets say we have a shared project parameter set to some category as a type parameter. Now make a family with that same shared parameter set as instance and load the family in the project.
Lets say we recreate the parameters with that same name as family parameter (so not the shared one) when editing a family and load it.
Maybe i missed it in your nodes but can you make something that solves this?
as # erfajo pointed out, this can be done manually from inside of Revit by the user. And, I’ll admit, it is easy to do. I was hoping to automate as much as possible for this overall Dynamo solution - to gain buy-in from the users.
So, I am needing parameters associated to the Room objects… the only way I know of doing this is through a Project Parameter… and since you cannot use it in both schedules and a tag, this is the reason it needs to be a Shared Parameter.
in a tag family you can add the same shared parameter inside a label, but make sure you have a shared parameter file
and as soon as the shared parameter is added to your project parameters
you can schedule aswell
the same values will be shown in schedule and tag alike
I did some searches here on the forum.
I dont know what version of Dynamo/Revit you are working on, but i can see talk about an OOTB node that does this., haven’t tested it myself, and i see a lot of post that speak of one parameter at the time, but still.
It all seems to come down at setting the shared parameter in your project first, no option to browse to the file, but i might be wrong.
It seems to me that @erfajo has a lot of experience with this, maybe he can provide a workflow/dyn
This might be a good start