Add a list of multiple parameters to a list of family documents

[domil96]

Revit, Dynamo and Orchid version

Revit: 2020.2 Dynamo: 2.3.0 Orchid: 230.0.3.7682

The issue

Hello, I'm trying to add multiple parameters to a list of family documents.

I managed to make it work with only one list of parameters (names, groups, types, etc.) by using levels (@L1 in this case). (So this works!)

Now I wonder if it's possible to do this with not just one simple list of parameters, but with an individual list of parameters for each family document. (See below)

So basicly what I want to do is, add all parameters in List 0 to Document 1, all in List 1 to Document 2, etc. as shown in the image above. (Obviously the lenghts of the sublists of the inputs are the same.) I want to do this workflow with the nodes SharedParameter.Add and Parameter.Add.

Is something like this possible and if yes, how can I achieve it? (I've already tried a few combinations of list levels and lacing, but I can't get it working.)

And if not do you think this function could be added?

Thanks in advance, domil96

[erfajo]

I suppose it can be done, using list level... but you need to tread carefully

[domil96]

Thanks for your fast reply.

So I've done a lot of testing now, but still don't get the correct results.

I have tried a lot of different variants of list levels for the inputs, but all I can get are error messages and null outputs, as soon as I have lists with sublists as inputs.

While testing I realisied, that even if there is an error on the node, there are still some parameters added to the families. However they wouldn't be added correctly. Sometimes the wrong parameters go to the wrong families, the parameter groups get mixed up or "type / instance" is wrong. This happens especially often when the sublist contains more than 2 parameters.

I also tried to give the inputs "tooltip" and "reporting" the same list structure as the other inputs. But it doesn't solve the problem.

The best case I got was this: But parameter group and type/insance is still wrong on some of the added parameters.

I've created a simplified version of my graph, added together with the .RFAs and the SharedParameter file in the attached .zip, so you can maybe test around with it. DYNAMO_AddParametersToFamilies.zip

Could you please take a look at it and see if you can make it to work?

Thank your very much.

[erfajo]

It will take some time before I have some spare time for doing that... you need to be very patient and I will not promise anything. I release my nodes without support for usage in all the settings they can be used in. I do only handle if they fail according to how they are coded/built.

[domil96]

Thank you for the direct but honest answer.

I can totally understand, that you can't support the nodes in all of their use cases, so that's fine for me. Still I would really appreciate it, if you could find some time in the future to look at it.

Until then, I'll put the graph far back on my to-do list, as it's not very urgend. :)

Nevertheless, many thanks for the efforts.

[erfajo]

I am rebuilding quite some nodes at the moment. The other day I released a rebuild and expansion of the IfcExport nodes. At the moment am I coding nodes for Datums, and along with that am I coding nodes for MEP components. So I am quite busy doing that. Along with that I am having a full-time job there not include my spare time where I am coding the Orchid packages.

So not to be unpolite, but it is some way down the road before I have time to look at your issue since it is not a programmatic problem.

[erfajo]

Hi @domil96 , I will just tell you that you are certainly not forgotten, but you made me think how I could do it better... So I am working on a total rethinking on how to work with parameters. I am sure this will help not only you but many others who actually dont want to create parameters but bulk add existing parameters to families and projects. I am having a scenario and hope that I am able to test it soon and release an update... I will inform you when it happens.

[domil96]

Hi @erfajo, awesome to hear that. Yeah, I also think most people want to bulk add existing parameters with your nodes. This was also the ultimate goal of my graph tbh. :)

So, not to get you wrong here, are you actually planning to make the parameter nodes work with sublists of different lenghts? And if so, is this going to apply for all the nodes of the parameter section?

Would love to hear from you about this.

[erfajo]

I am not sure I understand "Different length", så here is a test screendump. The below graphs are for families but I have also made the comparative nodes for project files.

BIM7AA parameters is a Danish community group classification expanding the old SfB classification and widely used in Denmark.

[domil96]

Oh, I think I got you a little wrong then. I thought you were referring to my original comment, and are planning to rework the nodes to behave that way. Because that would solve the problem with bulk adding parameters, as we could have a list of documents with individual parameters added. Like this: What I meant with "different lenght" is the amount of parameters in the sublists for each individual family document.

Don't get me wrong, I think the new nodes you created are in general a good idea, probably easier to use and would "do the job" aswell in lots of cases. But in my case for example, where there are different parameters, which should be added to specific families, those wouldn't work, I think.

The thing is, your new nodes would be redundant, if the SharedParameter.Add and Parameter.Add would support my suggested input structure. Even though it would require a litte bit more work beforehand to set the lists and sublists up correctly. Which is still all fine and doable with "standard OOTB list nodes" :)

I hope you can now understand what I'm trying to tell you.

[erfajo]

Adding just one parameter from a group is handled today using list level, I was looking into if someone would load the entire group. This solved also how to load all IFC parameters and comparative issues where you would load everything in an organized way. It could also solve your problem, since you could have a SP file with exactly the amount of parameters you wanted jo add to the file. that would be very easy to create such a file using notepad deleting lines you should not use... and in minutes you could move on, instead of working with list levels. You current SP will be set current again after running the "AddByFile" node... so no loss of work.

[domil96]

Adding just one parameter from a group is handled today using list level,

Yes that's right, but it only works for one set of parameters added to the families.

It could also solve your problem, since you could have a SP file with exactly the amount of parameters you wanted jo add to the file. that would be very easy to create such a file using notepad deleting lines you should not use...

This workaround could work. But it still means, that I need a SP file for each and every document containing the fitting parameters, assuming the new node accepts multiple families and SP files. So this would be probably more effort, than executing the graph once for each family document. (Which is my current workaround) Yet both tedious, as you can probably guess. (Might still consider giving this workaround a try)

Don't get me wrong, I still think those nodes are useful in a some situations. But in my opinion the method with lists and sublists gives more options and flexibility, which would probably help more people.

Of course it's your nodes and you decide what to do with them. I just wanted to give food for thought.

[erfajo]

I have released the 7711 builds of all verticals, So you can try testing if you can use the new nodes. I will keep this issue "unsolved" since it has a suggestion for an enhancement. I don’t have more time, for now, trying to build furthermore concerning the parameter nodes. I will try to return to this issue at a later point.