Search Issue Tracker
Fixed in 5.3.1
Votes
0
Found in [Package]
4.3.0
Issue ID
1111550
Regression
No
[Sequential] The sequential blocks and nodes should have greater parity
There are some cosmetic UX differences between the sequential blocks and their corresponding nodes (img attached).
Sequential Circle:
To match the block, the node should:
- Move Radius to the bottom
- Move Index / Count to the top
------------
Sequential Line:
To match the block, the node should:
- Move Line to the bottom
To match the node, the block should:
- Convert the Start / End to a Line input
------------
Sequential 3D:
To match the other blocks, the block should:
- Move Count X, Count Y, and Count Z on top, right under Index
- Axis X, Axis Y, and Axis Z should be spaceable
To match the other blocks, the node should:
- Move Index, Count X, Count Y, and Count Z on top
To be consistent, both should have the same name.
(I'm partial to Sequential 3D, but either should work, as long as the node and the block have the same name)
------------
Bonus:
Not sure if it's trivial to have a bool toggling an optional extra output (for target position), but it would make the nodes significantly more powerful.
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- OnPostprocessAllAssets() is not called for a modified Prefab when another Asset is set Dirty in the same callback
- [Android] UIToolkit ClickEvent is fired when the device is rotated
- Compilation errors occur when "uintBitsToFloat(int)" gets used in OpenGLES
- User Reporting does not send reports when Managed Stripping Level is set to Low or higher
- Editor crashes and a window with "GetManagerFromContext: pointer to object of manager 'MonoManager' is NULL (table index 5)" error is thrown when launching a project with a corrupted library
Add comment