This is the best product on the market in my opinion.
These type things look to be design issue(s). Seems like you would want meta-data elements like type id’s on nodes ? That way you could identify different ones.
But, then again, Why would anyone care ?
Just do it like you do everything else in life. “Look for It”
For me, 99.8% of everything I do in life, is just “Looking for it”
And “IT” always seems to be some type tool thingy I’m hunting.
In the case you cited, it actually does have an indication of what kind of node it is. It’s a ‘Param’ node named ‘SunColor’ with default value (10.0,4.0,0.1,1.0).
In general, many material and Blueprint nodes use a similar two-line header. The second line will indicate what kind of node it is, or the type of the Target pin it should be called on (for Blueprints), and the first line will be the ‘defining’ thing about that node, such as the name you’d reference elsewhere, or the name of the function being called.
That made a big difference. However, actually It is a “VectorParameter” Which I found after looking for quite some time.
Example: Let [A1] be a reference to the provided description.
If you will look at the Nodes Labeled “Texture Sample” and try to find the exact [A1] = “Material Expression Texture Sample” you will still
have difficulty finding the correct one. The [A1] description cannot be known until the node is selected.
These type issues are logical classification and/or Abstraction design issues which should be resolved during the design phase.
Most all software everywhere is riddled with these general quality deficiencies of various types throughout the software’s logic levels. It’s something we should all struggle to rise above.
I think UE4 is a wonderful tool and the best product available.
And this problem is not as important as some others, that’s why it exists to begin with.
I really believe we all want to do better.
However, we must live with what we cannot rise above.
