dr.sybren/rignodes
11
14
Fork 2
Code Issues Pull Requests 5 Projects Releases Wiki Activity

Condition Nodes #6

Open
Denys Hsu wants to merge 1 commits from cgtinker/powership:condition_node into main
pull from: cgtinker/powership:condition_node
merge into: dr.sybren:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 0 Commits 1 Files Changed 1 +140 -5
Denys Hsu commented 2023-06-14 20:02:41 +02:00
Contributor
Copy Link

Condition Nodes!

Conditional Value

  • May uses different data types as input
  • Choose a number of input sockets
  • Choose a socket as output

Conditional Execution

  • Uses a Solver Node as input
  • Choose a number of output sockets
  • Choose a socket for execution

Tested different naming conditions for the active socket, ultimately I preferred to just call it "Socket". It's confusing when the connect node name gets displayed when no proper naming has been done, also using the actual data type as name isn't to great. A unique name created the least confusion in my opinion.

Once more I'm overwriting the inputs (in this case, for the conditional execution node). In the LoopNodes PR I went for an _inputs and an _outputs property, it's also possible to overwrite the generators such as the exec_order_successors function here. It seems very useful in some cases to overwrite the input and output sockets. Using the properties approach might lead to less redundant code than overwriting in the end.

Condition Nodes! Conditional Value - May uses different data types as input - Choose a number of input sockets - Choose a socket as output Conditional Execution - Uses a Solver Node as input - Choose a number of output sockets - Choose a socket for execution Tested different naming conditions for the active socket, ultimately I preferred to just call it "Socket". It's confusing when the connect node name gets displayed when no proper naming has been done, also using the actual data type as name isn't to great. A unique name created the least confusion in my opinion. Once more I'm overwriting the inputs (in this case, for the `conditional execution node`). In the LoopNodes PR I went for an `_inputs` and an `_outputs` property, it's also possible to overwrite the generators such as the `exec_order_successors` function here. It seems very useful in some cases to overwrite the `input and output sockets`. Using the `properties` approach might lead to less redundant code than overwriting in the end.
conditions.png
252 KiB
conditions.png
Denys Hsu added 1 commit 2023-06-14 20:02:43 +02:00
Denys Hsu requested review from Sybren A. Stüvel 2023-06-15 23:13:01 +02:00
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u condition_node:cgtinker-condition_node
git checkout cgtinker-condition_node
Sign in to join this conversation.
Reviewers
No reviewers
Sybren A. Stüvel
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: dr.sybren/rignodes#6
No description provided.
Delete Branch "cgtinker/powership:condition_node"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?