It can already run the armature for ik constraint and rotation constraint?
I think not.
The real problem is that the nodes and in general the functions Iām putting in are the ones Iām aware of. Iāve never used armature (or even actions) in depth so I didnāt even think about constraints. Iāll try to see if I can find some resource on how they are supposed to be helpful. Once I get the reason why they exist I should also be able to figure out which parameters are needed and how they should be presented.
Okay, i would love to see that.
python can manage Action armatures, (or even a run armature actuator) however 95% is replicable using python.
armature.playAction()
however to sequence events properly I use a animation property and a action armature in property mode, but the limitation here is that property based actions in 2.76 (last I checked) never deactivate, (even when you send them cont.deactivate(actuator)
you can do this in python by using a zero action speed and setting the min/max frames to the desired frame, but itās not efficient cpu cycles wizeā¦
(it is kind of a can of worms)
when I say sequence events, I mean two or more actors actions being in lockstep, playing the exact same frame number.
armature.constraints is your path to messing with constraints.
/uploads/default/original/4X/a/a/2/aa25aea36e1724063a59a67ba7365d628b9251b1.blendd=1446101180 - I interpolate two IK constraints in this (be aware there is not much commenting at all)
I use it so in jump intial = play head jump animation , interpolate to aiming head at aimer.
Added an overview of the available nodes in a html page. It was extremely boring to make.
It contains a short description of each node and what it is supposed to do. If it doesnāt, itās a bug.
Wow so interesting 
Adding the bone channel-constraints nodes turned out not particularly hard. Iām still not entirely convinced of their usefulness but, well, it is now possible to edit individual bones and setup or change constraints. These are the writable operations that I took from the python api and associated to tree nodes and some hint of the possible usage.
The nodes will be in the next release. Along with 3D sound, if I find a way to play 3D sound. For some reason, the aud stuff doesnāt seem to be 3D at all.
Ah! Mystery solved then. Hopefully at least. Thank you very much, 3D sound was the last obstacle.
How about procedural generation with dynamic terrain loading via bge logic nodesā¦
Lostscience, that looks to me more a geometry production task than a logic thing. Well, it still requires logic but in a different context. Iām not sure if I would choose python to do that - I donāt think the current api can even do that because you canāt create new geometries, unless you use a geometry shader for that.
News.
Updated to version 0.1.0. Now with sound nodes. I didnāt add all the stuff one can tweak for a 3D sound, Iād like to do more tests before investing more time on the subject. It looks like it could work and it is certainly more fun when things can do āboomā.
The amount of nodes in the node menu starts to be problematic. I havenāt found a way to add sub-menus, Iām quite sure it is general relativity pales compared to that task. Yeah, UI api is still problematic for me :D.
So after the task is done, and all these nodes run python, how hard would it be to.wrap native functions to replace each python segment?
Is that how you would optimize this to be just as fast or faster then logic bricks?
Well, itās not hard, you just have to take the current logic brick system, throw it in the garbage bin and replace with the C++ version of the logic network used by the addon. I donāt see that happening any time soon.
Good news is that, despite its relative length, what the underlying python does is fairly minimal: lots of āisā, many ā==ā and many assignments. Thatās probably why performance has not been an issue as of now.
I think there is still room for optimization at the python level, to decide exactly how Iāll to run the addon on the cheapest pc I can find through a profiler.
Way before that though, I have to keep on finding bugs. If the outcome of a program is not right, optimizing it is not logically possible.
Updated to version 0.1.1 (end game node, mouse pressed on node, some sort of cache for ray casting, fixed a bug with mouse picking - incorrect distance, mouse didnāt pick everything it could).
Now Iāll try to use this stuff for a game, throwing in as many trees as needed and see how it performs.
Just an update on the first attempt.
I am amazed by the fact that this thing actually works. Iām trying to make a box that stocks dices with buttons to select the resource type and buttons to pick dices of that resource. I made a mess amounting to 44 instances running before to realize that I had no idea how the box should really work BUT the trees were constantly doing their job, despite deletions, additions, renaming, reordering.
On the second attempt, Iāll first figure out what I have to do, then Iāll translate it into trees :).
Very nice work man, Iāve been watching this thread for some days ago, and I will keep looking everyday for news, very useful, I will try to support you at least as a bug tracker, if I find any.
Iāve been reading about the future of Blender Game Engine, Tonās plans and stuff, but it still not clear to me what exactly they plan to do. Besides of the plans of turning the āGame Engineā into a āInteractive Engineā (as pointed in https://code.blender.org/2013/06/blender-roadmap-2-7-2-8-and-beyond/), I saw the video of Blender Conference when Ton talks about the plans to input the logic nodes for the āInteractive Engineā, or something like that (I donāt remember exactly the terms).
Do you think that it will be something like your work (in a practical way and the forms of usage, cause they plan to integrate the GE internally in Blender too), and whatās your expectation about those funcionalities and the future of the BGE?
By the way, congratulations for your addons, and cheers!
Thank you joelgomes1994.
On the subject of the future of āgames made with blenderā - bge as we know it seems to be doomed - itās anybodyās guess. Ton made a enjoyable description of the subject but a description is not a plan.
I think the action system will be similar, thereās only so much you can do with 2D nodes. You may call stuff conditions or sensors but itās just naming.
From a user interaction perspective, it is well known that it doesnāt work.
Well before visual content creation tools fell in love with it, integrated development environment had already tried to replace text with nodes.
What was found is that the visual representation becomes a mess as soon as your logic statement becomes non linear.
And thatās why we still use text files to code.
The add-on Iām writing shows it very well. Stuff like āif a then bā looks nice and clean. But when you start saying āif a but not b, unless c, until d then e for f timesā it becomes a unfathomable net of garbage.
At that point you start packing stuff into custom nodes andā¦ those are just wrappers for text files.
To this time, nothing beats a well written, stable, well documented api.
Itās a fun add-on to write though 
So, what was I saying, testingā¦ yeahā¦ AH AH AH. I did add more nodes. Actually I killed the Get/Set Global Values nodes and replaced them a Global Value system that can persist (if asked to do so) across game sessions.
The addition is a result of the āreal gameā test: as soon as you start doing that, you realize that among all other stuff you need a way to save data. Hereās the video test:
Persistence is achieved with a data logger. I wonāt annoy anyone with the details, it has benefits (itās very fast when running) and drawbacks (it may take a lot of space). Everything is saved in the same folder as the main blender file (//bgelogic/storage) - I donāt like writing stuff all over the user system. It stores strings, vectors, float, integers, list and tuples of the above things. It can be easily extended to support other data types but those are the only ones that the addon can manipulate.
The new nodes will be in the next release.
Front page updated with version 1.1.2 (more nodes, some fix), overview also updated to include the added nodes.
Updated to version 0.1.3 (the 1.1.2 I babbled about in the previous post was actually 0.1.2).
~Fixed&Updated Mouse Data parameter - the data was not consistent with mouse condition states, added delta wheel;
+Mouse Wheel Condition
+import math in node scripts - so one can use expressions like math.pi / some
+Update Sound has now optional volume and attenuation - when none the previous value should be kept
~Did something to Edit Armature Bone - canāt remember what
~Started splitting node categories into more manageable menus
Updated front page video with cinematics node (Move To, Rotate To, Move To with Navmesh). If the destination point is set to the position of a moving object, they act like āfollowā actions. Maybe, I didnāt tested that yet, but thatās the idea.
I want to add a āmove along pathā node to do patrol-like actions but Iām still thinking how to let the user specify a path - possibly not by inserting a ton of points by hand :).
When Iāve got that, Iāll publish the 0.1.4 release.
When thing I never mentioned which is quite important: tree names uniquely identify the corresponding logic network. Two trees with the same name, even if defined in different blender files, overwrites each other. Itās probably the last key issue that keeps thing in alpha (= donāt really use it) state, because to fix it I have to change the naming schema of the trees and that will break all existing experiments (unless I start using some kind of versioning, that will complicate an already complex add-on).
Excellent work pgi ā¦ This moves BGE forward
It works even in older versions of Blender?