"required"
inputs were actually validated. If you had custom nodes that were only ever connected to "optional"
inputs, you previously wouldn’t have been seeing that they failed validation.
"required"
inputs, it is unlikely that anything in this section applies to you. It will primarily apply to custom node authors who use custom types and exclusively use "optional"
inputs.min
and max
on types that aren’t comparable (e.g. dictionaries) in order to configure custom widgets.
uiMin
and uiMax
. (Recommended Solution)
CUSTOM_A,CUSTOM_B
)
MakeSmartType
seen here in the PR’s unit tests
input_types
argument so type validation is skipped.
@VariantSupport
decorator seen here in the PR’s unit tests
[1, 2, 3]
) as constants in the graph definition (e.g. to represent a const VEC3
input). This would have required a front-end extension before. Previously, lists of size exactly 2
would have failed anyway — they would have been treated as broken links.
{ "value": [1, 2, 3] }
VALIDATE_INPUTS
function in order to lessen the impact of the Optional Input Validation mentioned above.
VALIDATE_INPUTS
function.VALIDATE_INPUTS
function can now take **kwargs
which causes all inputs to be treated as validated by the node creator.VALIDATE_INPUTS
function can take an input named input_types
. This input will be a dict mapping each input (connected via a link) to the type of the connected output. When this argument exists, type validation for the node’s inputs is skipped.