Logic node able to know what type is some object.
For example the projectile must know when it is in contact with and object, is that object the player, it is some destroyable object, some ai object or the environment.
Projectile object logic node to commuincate and send values to another logic nodes
For example when the projectile is in contact with a destroyable object , it sends some information to that destroyable object like damage to apply, or call a function.
Without those further gameplay is not possible, i didn’t seen anything related in the manual.
So I think I’m going to try to implement some features for nodes to help with this. There is already a Get Trait node that can be used to get the trait of the object that your bullet hits; it just remains, then, to provide a way to create “On Node Function” event nodes and “Call Node Function” action nodes that can be used to call the logic.
Then when an bullet hits an object you can just say, "Get Trait get Damageable of collided object, if trait is not null, call node function damage". Sound good?
I think we could do something like that at least for nodes. We might want to do it for Haxe traits as well. Currently there is a Call Haxe node, but it doesn’t let you pass arguments to the function.
For logic nodes there is no functions, it would need something like CallLogicNodeTree(LogicNodeName).
The other issue is there is no parameters for logic nodes, some way could be using attributes
SetAttributeLogicNode (LogicNodeName, attribute name, value).
A LogicTree is actually a subclass of iron.Trait, therefore, with some modification of the logic node compiler script, we should be able to make onNodeFunctionCall and callNodeFunction nodes.
You can get the information for part one by seeing if the projectile hits the player. And if so do what ever. You can get that with the get first contact node or the get contacts node. As for 2. again you can do all this is just isn’t very pretty in the node set up and could get very convoluted depending on all you want to happen. But it is possible to do.
for example test if the projectile hit the player and if so change the health of the play with properties.
When you start talking about multiple object being “destroyable” then you start to get into tags or something else that identifies all those objects as being the same for this specific purpose. You can do this by setting a property, say destroyable for each item as a boolean. This would get crazy quite quickly but the backbone for what you want to do is there.
I agree that we need to work on “subroutines” ( I think that would be the right terminology) for nodes and be able to pass more information from one group to the other.
Events are slower than direct access to property.
I would like a callFunction(trait name, function name, params)
It’s what i used properties.
Well … we need tags and layers, not Blender display layers, but logic layers.
Most of the time layers are used in combination with physics (contact, raycast, collisions) , to tell what objects can or can’t collide with other objects.
For example some object will collide with projectiles while another will not collide with them. Or raycast will only detect some specific layers.
Some example :
Tags to quickly define some object type without having to code, directly in the editor enter it’s tag name to identify specific type of objects , for example tags like “resource planet” “resource rock” “creature friendly” and so on.
That is exactly what I see a trait as. You handle it like an interface in object oriented programming. If you hit an object, check if it has the “destroyable” trait. If it does, then it will, by definition, have a “destroy” function that I can call to destroy the object. I think this represents a very clean solution that keeps the separation of concerns between different objects. Each object can easily think about itself, and deal with other objects through the traits that it knows how to interact with.
That is kind of cool. Something like that could be useful. I don’t know exactly how you would implement it for something other than physics.
Exactly it’s used for physic, but also for gameplay.
And optimization.
Inside a big collision volume following the player you test only the layer “collision sphere path” to get possible nearest path at any time, instead of testing all your open world objects collisions.
Traits are what Armory calls any logic attached to an object. So at the very least a different term needs to be used. It is essential a specific use of a property.
@MagicLord, I guess I don’t know how to say this quite right. Armory isn’t Unity or Unreal. It is in Alpha/Beta and it seems you are at the mercy of guys who can code. So, you either have to use the ideas and methods that are offered or productively work with someone willing to work on the code to get your desired result. Several solutions have been offered and for now that is what we have to work with.
Also, your comment about blender modeling is the entire reason many people will use it. The point is to make a game engine that you don’t have to leave the DCC app to work in. So armory has to work like blender. You can’t make it into something it just can’t be. As long as it is a blender Add on then it has to work within blender’s way of doing things.
The problem in logic node you can’t do anything when you get trait, there is no variables or functions acess. It find some usage only to pause and resume traits.
This is not usable for communication.
I think this is what was needed in logic nodes to communicate directly with other objects functions. This is lot more optimized than using events.
Again it’s not changing Armory in anything, it’s bringing some features needed to make games. It’s a really great improvment for logic nodes.
This will be great usability and improvment for efficient objects communications.
We shoud not need anything more, or perhaps some more arguments in and out
