Communication between objects

It is dynamic. You can add and remove as many as necessary.

Can you explain how you would create functions in nodes. Would you just set up a node tree that works like a blender material node group? There would have to be a way to send the arg in and arg out of the “Group”. I assume you already thought of this. I have been thinking alot about how this could work. This seems like a create start for what I think of as “Subroutines” Animation nodes uses them. If you able to look at that code it might help you work it into a system. But then I may be way off on that.

I won’t behave exactly like a material node group. The Function node is essentially just like a On Event node. I want it to compile to a function in the generated Haxe which will will let you call it with the Call Function node. You will also need a Function Output node that can be used to set the return value of the function. There technically won’t inherently be anything grouping the nodes in the function, but you can use Frames to create a visual grouping. A gun fire function might look like this ( this function doesn’t need to output anything so I don’t have that in there ):

Sometime I’m going to check out the Animation Nodes plugin that you linked to earlier. I might be able to borrow some ideas from that.

1 Like

Check out the animation nodes playlist for this guy. I think it would give you a quick idea if studying would be helpful.

1 Like

I already made a way to create functions in nodes, it is here in logic_pakc:https://github.com/armory3d/logic_pack/pull/22#issue-222248950
you have 2 nodes between which you make your function/method, and two nodes to call and return those functions (return not necessary for it to work, only if you want it to return values)
Or do I understand it wrong, do you want to use the function you made in a Haxe script to be called by your node with the nodes parameters? Then your node would really be a cool addition.

Oh, cool. I wasn’t aware that anybody had done something like that before. I just finished my setup yesterday. It looks like it is a bit different from yours.

Calling a Function:
image

Defining a function:
image

I repurposed the Call Haxe Function node as a Call Function node and added dynamic number of arguments. The more special part is that the Function and Function Output nodes actually compile to functions in the LogicTree trait. That means that functions defined with nodes and Haxe can be called from either; there is no barrier between the two. It wasn’t as simple as writing new nodes, I had to modify the node compiler a little bit to get the Function and Function Output nodes to work right, but I think the result is awesome. :slight_smile: It adds a seamless way to communicate between objects though traits, regardless of whether or not they are Node or Haxe traits.

I’m going to review my code a little bit more and then submit a PR for Armory. Tell me if you have any suggestions.

3 Likes

@zicklag and @Simonrazer

I talked about this in another thread but it seems you two have the coding ability to take it on. Could we create a node that has an object AND the ability to add multiple properties? It would be awesome to put a object into a node tree and automatically have access to all its properties from that node. Maybe, you would need two nodes one to set the object and properties up and one to call it and pull the properties from.

Does this make sense?

I just opened a PR to Armory core for Node Functions. It requires changes to the node compiler so I couldn’t add it to the LogicPack.

What kind of object properties. Like native properties from the Haxe API or ones set through the Blender interface?

No, just properties the way Armory nodes uses them. For example one node that when you add say the player object you would have outputs of what ever properties are attached to that player. ( Health, power, mana or what ever) That way you don’t have to add get properties for everything you want to use and also could use a boolean variable as a type of tag as discussed in another thread.

Not sure if this is possible or if using the functionality of nodes linked above would be a better way, but it would seem to solve a bunch of “spaghetti” and repetitive nodes in a tree. Just putting the idea out there.

Ah, I get it. So you would want a Object Properties node that will show a value output for every property that is added to a given object in Blender. So with a search box to select the object and an output for every property set in Blender.

I think technically that would be possible. It couldn’t use a Object input socket to select the object, because that is determined at runtime, but if you used a Blender object searchbox that should be possible. I’m not sure how well that would work for objects that you have multiples or duplicates of, though, because it could only get the properties of a specific object in Blender. We’re limited because the node can only determine the properties of objects that exist in Blender, not ones that are spawned or determined at runtime.

Right now I’m working on a more intuitive way to handle variables.

2 Likes

I think you get the basic idea. If your way of handling variable solves the problem great. Lets see what that brings and I will check back then.

This looks like Property, instead it has many variable inputs and outputs ?
Like some structure ?

1 Like

Yes I think that is a good way to say it. It would be awesome if it all the info came right with the object. Especially, as you discussed before, for player and things like walls and other objects what would have the same properties even if they were not “prefabs.”

My node functions PR got merged. Yay! :slight_smile:

3 Likes

@zicklag I just rediscovered your post and your according nodes in Armory. Thanks a lot , it’s very useful to improve the possibilities of a full object programming in Armory and as I am in the redesign of all ATRAP, I plan to use it a lot :wink:
(I have experienced before that the use of a large number of node trees and events can become a nightmare in the end when you have to debug with a large number of nodes and events to remember as we have not the tools to make search or to print node trees in a usefull way today )

1 Like

@zicklag … I would like to discuss in a few words with you how to consider the object-oriented programming** evolution that your call function allows now.

** If we start from the basic principle that we must be able to work with objects that are instances of a given class, with datas that correspond to the properties of the object and behaviors to the methods of the object

Within Armory, we can go through several paths to establish an object-oriented approach that will allow an object to invoke behaviors of another object by delegating the implementation of these behaviors to the called object (via the traits, node trees events, parenting, class extends and override function in nodes,…).

From your evolution (Call Function, Function, Function Output), in the sense of a full object-oriented programming, how do you see things?

My first thoughts are, if you were to ignore any form of static typing or type checking, you could achieve something along the lines of an object oriented approach with function nodes and object properties, things that we already have at this point. But that has absolutely no inheritance and little encapsulation, as attributes are on the Armory object, not on the trait ( aka. NodeTree ).

Another approach could be to create a more advanced, “Object” node that lets you click “+” buttons to create new attributes and methods on the object with the possibility to choose an inherited parent class, but then you have to make a decision between compiling to static typed Haxe and throwing compiler errors when you arrange your nodes incorrectly, or doing everything dynamic and throwing exceptions at runtime.

Another thought is maybe creating a special workflow for creating “Classes” separated from typical traits through Node Trees. Each class lets you add Functions, which are node trees by themselves, that have a “Class Inputs” node that gives them access to the class attributes. Inheritance could be handled by that somehow as well. It would be best to have some type checking done inside of blender so that you don’t have to compile the game to find out that there are issues.

That is just my very quick first thoughts brainstorming. I might think more about this later.

In the light of your initial thoughts, I think maybe that the best limitations/constraints that could help to focus this brainstorming, could be to favorize here an approach that favorize improvement of code safety and maintainability by using the compiler to find errors rather than with runtime errors, and using only what we have in hands today.

1 Like

Yes, I think that, similar to the current function nodes, an approach to try out initially should seek to make the nodes compile to Haxe that is as conceptually similar as possible to node structure. If we have some sort of node “Classes” those should compile rather straight forwardly into Haxe classes. Like the function nodes that actually compile into Haxe functions. That makes it as seamless as an integration between Haxe and the logic nodes as possible.

1 Like