Default Custom Node Input Values

Hi All,

Been looking for a while but cant seem to find the answer, if there is one, to my question.
I know that Input nodes within custom nodes can have default values set for them.
My question is is the following possible?

Input Node (Input required is a String) but if none are provided an “Empty List” is substituted.

If there is another way to allow a custom node to run without all inputs defined Im all ears!

Thanks :smiley:

Hmm I just tested this out and it seems if you put the input in your code block as: enter : string = DSCore.List.Empty it will work :slight_smile:

not 100% certain though, I only tested by passing the input through a Python script that does nothing :sweat_smile:

Thanks @awilliams ill give it a try and post what happens :+1::smiley:

Thanks for the input on the default inputs @awilliams , I think this is working now.

I went with input: string=null and did some post processing, so now the node will run with no inputs other than the elements.

I have a little problem with one of my nodes that I cant put my finger on.
The contents work fine in the work-space but it appears when putting into a custom node the Python go’s a bit wonky.
It appears to run the function defined in the Python node for the number of times equal to the element in the input list.
This causes the values to be misaligned and only one value is written to the element.

Can anyone advise?

I’m a fast typer so I don’t really mind, but could you paste your Python code as preformatted text to make it easier to have a look at :blush:

1 Like
import clr
from Autodesk.Revit.DB import *

import Revit

import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

doc = DocumentManager.Instance.CurrentDBDocument
items = UnwrapElement(IN[0])
pre = UnwrapElement(IN[1])
abv = UnwrapElement(IN[2])
val = UnwrapElement(IN[3])
bel = UnwrapElement(IN[4])
suf = UnwrapElement(IN[5])
worked = list()
didntwork = list()
counter = 0

while counter < len(items):
		items[counter].Prefix = pre[counter]
		items[counter].Above = abv[counter]
		items[counter].ValueOverride = val[counter]
		items[counter].Below = bel[counter]
		items[counter].Suffix = suf[counter]
	counter += 1

OUT = (worked,didntwork)

Set Dimension Overrides.dyf (21.9 KB)

Thanks for taking a look. A little off topic but it should round trip back to the input parameters eventully :smiley:

Hi @Ewan_Opie I just had a look; I haven’t given much time to seeing how this can be worked around just yet but thought I would still chime in to tell you what I see occurring when I run the script.

Changing the lacing to Longest on the .dyf solves the issue of the value only being written to one element, but the misalignment of values appears to be due to the values being assigned to the dimension elements in the order of element creation (so based on Element ID).

The only way I am able to assign values in the order I want and without the last value being applied to remaining elements (due to lacing being set to longest) is to structure the other inputs to follow the order of Element IDs (example below, I’m telling the custom node to give Element 414714 no prefix, then 414721 prefix “pre2”, 414728 “pre3”, 414240 “pre1”)

I’m at a loss for how the inputs would be correctly associated with the correct elements without an extent of manual list structuring of the other inputs, but maybe I am misunderstanding what you were trying to feed the node. I might be wrong but I’d speculate the Rhythm Dimension.Set___Value nodes are separated (i.e. SetBlowValue and SetAboveValue are separate nodes) because then there isn’t a situation where you’d be feeding a dimension that you didn’t want to set a value for. :thinking:

Thanks for taking a minute to have a look. :+1:

Yes, I can see the logic in what you mention about the #rhythm package layout with separate nodes.
“no inputs? why change it?”… and I am inclined to agree now.

Consolidation of processes can sometimes be of benefit to a workflow, but assessing if it actually more efficient is another thing. I’ll take this on-board, and probably evolve this node into something else entirely.

As for the original posting on Default Inputs for those looking for answers regarding custom node input default inputs. @awilliams solution does work. :clap: :+1: (input: string=null) also returns a non string null value, could be useful for some.

Otherwise, consultation of the primer is a must do for all looking into custom nodes.

Screenshot of outputs from default inputs below for reference. :grinning: