Logic node improvements

Hi,

this issue is a continuation of the discussion started in https://github.com/armory3d/armory/issues/1786. In my opinion, there a quite a few things about logic nodes that need discussion and very likely some improvements. I’m collecting them in this issue:

• There are multiple similar nodes where the differences might not be very clear

  Do you know, without looking, what the difference between “Array Remove” and “Array Remove Value” is? Or what is the difference between “Collection”, “Set Collection”, “Add Collection” and “Spawn Collection”?

  So, some nodes need a renaming

  For example, there are two Set Camera nodes with different functions. It would be better to name them “Set Camera” and “Set Camera Settings” or “Set Camera Data”.

• Some of the larger categories like Action and Value urgently need to be splitted in smaller ones

  Scrolling in Blender’s menus is a pain^^

• Set and Get nodes for the same thing are in different categories

  I think it would be better to sort the nodes not according to their kind of function (get, set, etc.) but to their subject like it is done for some categories already (Canvas, Physics, Postprocess etc.). Also, the “Variables” and “Values” categories are hard to distinguish. We could use something like this as an inspiration (Source):

  

  If implemented exactly like in the picture above (with icons and layout separators) that would need a custom drawn menu but it is possible (source code) and it probably would also allow us to use the node’s bl_description values as tooltips when hovering. Currently, Blender only shows Add a node to the active tree as a tooltip. If we decide to implement such a menu with icons, we can also update the nodes to show the correct category icons in their header. We maybe even could add sub-categories that are separated by those separator lines like in the screenshot.

  Changing the categories and/or the node names should not destroy already existing node setups so I don’t think that there are big backwards compatibility issues.

• The documentation page in the wiki should be sorted regarding to the categories.

  Currently, the nodes are sorted in pseudo-categories (that might once have existed, I don’t know) like “Actuators” and “States”. That’s not helpful for somebody who is looking if a node exists, and many nodes aren’t documented at all. Maybe there should be a single page per category for less scrolling? On the other hand, one big page makes it easier to search with Ctrl + F if the category is unknown. Also, there should be a page in the documentation that describes loosely how nodes work and what the different socket types stand for.

What do you think?

[luboslenco]

@luboslenco Are you fine with such big changes?

Sure! If it’s for the better we should not hold back, and I am happy other parts of Armory are moving forward while I focus on the lower level internals.

[MoritzBrueckner]

Self, Parse float, In Array, Cast Physics Ray and Collision Filter Mask are renamed now, thanks again 😃

I wouldn’t rename Mask as it just returns an integer that might be used elsewhere (and also might have its use case in the future). Because nodes are now sorted in other categories and show an icon based on their category, the same goes for Get/Set Visible, I think it’s sufficient enough, otherwise we would have to rename the getter/setter nodes for meshes, parents etc. too.

In my opinion Scene Root is a good name as this is what it’s called. Scene Objects would suggest that the returned value is an array.

Also, traits don’t need to be node trees, they can be scripts and canvas traits too.

About the merging of the mouse nodes: I have no opinion on that other than there might be cases where only one of those nodes is used.

The removal of deprecated nodes should wait until we have a proper node replacement system in place, @niacdoial seems to work on one. In the meantime, we could mark them as @:deprecated in the Haxe code so that they raise warnings on export.

The Expression node can have is use cases (even if rarely used), for example if you have more complicated conditions/equations and you don’t want to use a bunch of nodes for that. Regarding the Speaker node, I don’t know about how complete the support for speakers is in Armory but we should keep it.

@ everyone:

If you want to test the current changes, check out this branch: https://github.com/MoritzBrueckner/armory/tree/logic-nodes. It would be great to get some feedback especially about how the sections are divided.

Thanks!