Do you aprove these Logic Node changes?

Armory Engine Logic Nodes
1

Logic Nodes was meant mainly to make possible non programmers to create logics. They can speed up a lot of things and provide a faster prototyping of mechanics and can be combined with written scripts, but they have the focus on people that need simpler things.

This topic is intended to get your opinion about a large change in the nodes names and layouts. All this changes was meant to new users and practicality based in what i have experienced this time using nodes. Unfortunately everything has a con, and some of these changes will break compatibility with existent logics.

Here is the list:

  • Nodes to be rennamed:

Show Mouse > Set Mouse Visible

Set/Get Location > Set/Get Object Location

Set/Get Rotation > Set/Get Object Rotation

Set/Get Object Scale > Set/Get Object Scale

Set/Get Object Visible > Set/Get Object Visible

Window Info > Get Window Resolution

Display Info > Get Display Resolution

Get Trait > Get Object Trait

Get Velocity > Get Rigid Body Velocity. This will avoid people trying to use this node with a character moved by Translate Object for example.

Add Trait > Add Trait To Object or Append Object Trait

Case String > String Case

Contains String > String Contains

On Canvas Element > move to Input category.

Get World > Get World Orientation

Render Path category > various to be renamed. Such as Rp MSAA to Set MSAA Quality

Pick Object > Get Rigid Body On Cursor, because it works only with rigid bodies.

  • Nodes to be merged and improved:

Pick Object: Implement Collision Mask.

Send Event: merge with Send Object Event with a drop down box.

Get Mouse Lock and Get Mouse Visible: merge to Get Mouse Data.

Split Mouse Coords to get rid of Separate XYZ and Vector everytime. Implement Invert Y checkbox or change for a drop down style.

Add RGB inputs to Color variable.

Add Left and Down drop boxes to Vector From Transform and Get World.

Create a Clamp node as Clamp Vector node.

New: remove the default values from nodes like Vector Math. Reason: What is the last time you used this values? Most of the times you have to reset one of these values to don’t have effect or change it.

Feel free to discuss these changes or suggest other changes ^^

1 Like
2

Also there is a not called “Get World”, i don’t think that this is a sugestive name and i don’t know what is its functionality. Why there is a option to “Look, Right, Up” and not for “Down” and “Left”?

3

Agree with that :slight_smile:
And why not change the “Vector from transform” that also has Look, Right, & Up, and we never know if it’s for x, y or z…

4

Indeed. People coming from other engines are used to other “axis” parameter. In Godot For example, the Z axis is not the “up” axis. They can become confused with this.

By the layout, Vector From Transform looks a more flexible and complete version of Get World. Maybe it is the case to cut off the Get World node. Or they have different purposes?

5

It looks pretty good, so I will constrain this to the few nodes where I do not fully agree.

The new name might be a bit long.

Get Mouse Data sounds very abstract to me and might be rather confusing, especially when still having Set Mouse Lock and Set Mouse Visible as nodes.

It comes from this: https://armory3d.org/api/iron/object/Transform.html#look (also #up and #right). Those three vectors are the base vectors of the local coordinate system and sufficient enough to be combined to any other vector. To get the opposite direction, a simple multiplication with -1 is enough. But I agree that we should probably just make all directions available.

Also, the name is indeed horrible. Maybe something like Get World Orientation or Get World Directions? The world part is crucial because the direction vectors are given in world coordinates, otherwise they would just be (1, 0, 0), (0, 1, 0), (0, 0, 1).

6

About the Pick Object, i agree that Get Rigid Body On Cursor is really big. But i could not find a more descriptive name, as the user must use it only with RBs. The truth is that Pick Object is not good, the object is not even “picked”. Maybe Rigid Body On Cursor, i really don’t have any idea here.

Get Mouse Data: i also agree that this name is very vague, there is no “data” in a mouse. The only reason because i want to merge this two nodes is to merge Set Mouse Visible and Set Mouse Lock into a single node with a drop down with: Lock Hidden, Hide and Lock. This is the rare case where we can’t do nothing except put a Get Mouse and Set Mouse names. Is vague but…

Get World is really a bad name. I had opened a feature request asking for a “Get Relative Location” and i think this Get World do this work if i am not wrong. The relation of Vectors in Locations and Rotations are very confuse for me. Maybe you can see how Unreal had nammed a blueprint that do the same thing. I think its called “Get Relative Location” but i am not sure.

1 Like
7

Added a new element in the topic (see * New)

8

Get World is horrible, yes. Get Relative Location would be wrong though because those are direction vectors that describe the object’s orientation/rotation. I personally would call the node Get Object Orientation or Get World Orientation.

The default values for the Vector math nodes could be set to 0, but we shouldn’t remove the possibility to set them to constant values directly in the node.

1 Like
9

I had merged Set Mouse Lock with Show Mouse and Get Mouse Visible with Get Mouse Lock. My OS is hiding the mouse when i lock it even with the default Set Mouse Lock. If someone can confirm if it is working on Window properly, here is the nodes: https://drive.google.com/file/d/15XuFAcGDqZdECWgzYLNGTihovIZu2uK9/view?usp=sharing The download is in drive because forum don’t allows .zip

Any suggestion is welcome :slight_smile:

10

I do one more step that is not in the list, but don’t cause any incompatibility. Changed a lot of sockets names and now they are more specific.

  • Physics nodes now specify that only Rigid Body objects are accepted.

  • The same goes for cameras, lights, etc.

  • Give a less repetitive names for variables like you can see in String variable (now it have String In and String Out

  • Booleans now are more intuitive. Now instead of Visible for example will be Is Visible.

  • When a variable is not that specific i just use the variable name instead of Value, except for those that uses Shader Socket.

  • Arrays now are just the values given in plural. Example Get Contacts now have a output named as Contacts instead of Array.

  • The change was applied to more than 60 nodes (i don’t know how to get this info now as they are in folders :slight_smile: )

  • I just don’t know what comes from the Split String node. It is using Array output yet. Do it return separated Words?

screenshot1
screenshot1612Ă—530 42.9 KB

11

Armory3D - Gate
Unreal Engine - Gate
Godot Engine - Condition
Unity3D Bolt - Branch (only)

Why doesn’t anyone like the name “IF” (in short, “IF … ELSE”)?
In all books, IF ELSE is taught in all languages, but here…

12

I believe that it is necessary to define the rules (standard, template) of naming, because nodes will be added and changed. Using a template, everyone who creates them will name them “correctly”.
As a result, the name will not be spelled correctly in English, but we are in a book club. =)
I would like to propose to formulate the following pattern:

  • For objects:
    [operation] [name] [property]
    Operation - Set, Get, Remove, Add
    Examples:
    Add Object Rigid Body
    Add Object Traits
    Remove Object Traits
    Set Action Start (!)
    Set Action Pause (!)
    Set Sound Play (!)
    Set Canvas Scale
    Set Canvas Text
    Set Camera Active
    Set Apply Force (!)
    Set Mouse Visible
    Get Mouse Visible
    Get Camera Active
    Get Keyboard State
    Get Window Resolution
    Get Object Location
    Get surface coords
    Get Gamepad Coords
    Get Random Int

(!) - objects that may need a separate category in the template with their own rules.

  • For events:
    [event] [name]
    Events - On, Send
    For example:
    On Init
    On Update
    On Keyboard

  • For data types:
    [name] [operation]
    For example:
    String Split
    String Sub
    String Case
    Float parse
    Vector Separate (instead of Separate XYZ)

Further, logical operations, utilities/tools (Timer, Native category) should be considered as separate sections of the template.
This makes it easier for the user to search, especially for a newbie, reminiscent of distribution by package, or namespace in code, or just sections in a menu.
What do you think?

13

Gate node is more an “extra” node, because we can use Compare connected to Branch node. I don’t like when there is extra nodes, but in some cases is acceptable.

Is not a good idea to change it to “if else” because it is against the principle of nodes (that is being friendly for non programmers).

About the standard nomenclature i like it, but in some cases it will be against the usability. It need to be flexible. For example, if i name a node as Get Velocity i am not specifying what is the velocity i will get and from where. If i put Get Object Velocity is better but also is not the maximum specific and there is more than one way to get a object velocity that is related to physics and vectors. In this case i would go for Get Rigid Body Velocity and Get Object Velocity i would use for a velocity that is given by a translate method. Also if the user search for velocity in the node menu, will appear both velocities types for he choose.

Also changing too many nodes will introduce more work in the wiki and updates on them, it need to be only the necessary to get the nodes “stable” and after it we start to define its descriptions and documentations: https://docs.godotengine.org/en/stable/community/contributing/best_practices_for_engine_contributors.html

I also would like to rename Not to Invert Bool.

14

Merged and splitted nodes:

screenshot1
screenshot1902Ă—504 65 KB

Now is possible to configure the “sensibility” and if the value is inverted or not directly on the node, but i had to split movement and location in two nodes. Anyway it will also help to organize these nodes.

1 Like
15

@timodriaan , nodes like “Remove Object”, “Remove Active Scene”, etc. just removes these things or they delete?

There is a difference between this terms: https://apps.labor.ny.gov/ux/doc/v1/design-remove-vs-delete.html

After removing a object or a scene, i can “spawn” them again, or they are erased?

16

They just remove the item but not delete it. I’m not entirely sure about the “Remove Collection” node, that looks like it really deletes the collection from the game data.

1 Like
17

@timodriaan , i tested here and removed objects indeed can be spawned again. Remove Collection seems to is not working, or i am using it in the wrong way:

  • Create a new collection nammed as Test (trough the Blender UI)
  • Put a cube inside this collection
  • Use Remove Collection (Test)
  • Nothing happens

I expected that the objects from this collection must be deleted. Or they simple become with no collection assigned to them?

18

The spawned instances remain in the scene, you have to differ between the group (= the information which object belongs to that group) and the actual spawned objects (you can spawn collections multiple times, which one should be deleted? It’s difficult).

So, the data is in fact deleted and you won’t be able to spawn that collection again. To delete an instance of a collection you would need to keep track of the root object, maybe we should add some way to determine if an object is in a group and some way to get the object’s group root object.

19

We need to create “Get Object Collection” node? I think it should be easy to do

1 Like
20

If I remember correctly Iron only keeps track of the group of an object when that object is in the groups “top level”, so children objects would need to iterate through their parents to get the group.

It’s a good idea :slight_smile:

1 Like