[DEAD] Blender Plugin - BGE Logic nodes - Alpha

Game Engine Works in Progress and Game Demos
21

Well, how do they say, f-it, I did it. I posted a testable version of the add-on and very poor guide. Links in the first message.
The guide is so poor I’m ashamed of it but it’s the most I could get out so far. The system, while very linear at his core, has become quite big to explain in details. I will improve the guide if the add-on passes further tests.
There’s no need to say that this thing is very “delicate”, at the moment. I didn’t tested it thoroughly and it is very likely working for me just because I know that it does, so I don’t do what it is possible from a user interaction point of view but the system is not tailored to handle.
Start blender from a command line, so when (not if) something bad happens, the underlying script will hopefully say something about it.
There’s not user guide - there will be one some day in the future - but there’s a small chance for the add-on to be intuitive.

Now, minus some quirks (like connecting an orientation to a vector socket, using the result of a FindGameObject that returns None because the object has not been added, using the same name for two different trees), the add-on should work.
Applied and activated logic trees should be executed when the game engine is running. The interface should have the obvious effects. A MousePressed should react to a mouse press, and EndScene should end a scene, a PlayAction should play an action and so forth. If it doesn’t, that’s a bug.

DISCLAIMERS

The plugin writes and overwrites files, found in the same directory of the current blender file. Specifically, it writes “.py” files in a subdirectory named “bgelogic”, located in the same directory of the opened blender file. Only there and only that, but it still overwrites: if you create a python file named “NLMyPreciousMemories.py”, put it in a bgelogic subdirectory of your current blender file, then create a logic tree whose name is stripped to “MyPreciousMemories” than you can say goodbye memories.

As for the stability, I’m practically changing stuff as I speak. Some changes are disruptive, meaning that once in place they make existing trees work no longer, so whatever you do with the add-on, it might not work again if an updated version sees the light.

Have fun with it and, if you want, report back the errors that you will (almost certainly) find.

22

I wonder if after you get it up and running, if the code for the nodes can be rewritten in C by someone like sdfgeoff, so you get all the potential speed and your added flexibility?

If each nodes functions could become native, and wrapped in python…

23

Actually Ton has planed to to make logic nodes https://www.youtube.com/watch?v=spKJ2jbnVI8 (time 40:40).

But I would prefer the custom nodes. So we only need to maintain python API.
Actually I don’t have done a speed comparison between C++ and Python. But I think the speed difference shouldn’t be very dramatical, if the produced code don’t have to much overhead.

24

Right now there are no optimizations in the code, even blatantly obvious ones, like not checking all conditions when one being false is enough to discard the cell, not caching values, so there might be a chance for the add-on to be fast enough by itself.

That said, I think that the foundation already has something in store because I read somewhere (like in the sky) that the interactive viewport will have actions controlled by logic defined through nodes. Let’s wait and see.

Btw, I just finished writing “The Behemoth”:

http://www.tukano.it/images/fpscontroller.jpg
fpscontroller.jpg770×590

It doesn’t look very user-friendly :smiley:

25

Remove always, connect up mouse move, and keyboard any?
Property jump not zero?

26

I can’t think of removing any of them without loosing the required flexibility. Like using more controls for a single action (W and ARROW UP for moving, or arrows for rotating the head, or a set of keys plus a controller state). I will add predefined values, so that the user finds a WASD + mouse setup, freely configurable into something else.
Of the predefined nodes I think this is the only one that really looks that huge. But I still have a ton of them to add, so never say never! :slight_smile:

27

I only meant to activate,
So it only is running when the player is pressing stuff, or the mouse is moved, or jump or fall is in process.

I also tend to use a little clock, so the script plays the idle animation for x before going to sleep.

In logic/py

If keypress any-----python
mouse move------/
Jump not zero—/
Clock not 30—/

28

Ahhh, the main condition. That’s just a matter of having conditions and combining them, actually there are just a handful of them. I have added a time one few minutes ago :slight_smile:
The actual computation carried on in the cell is really not heavy, there’s a bunch of “if X is …”, which are quite happily mangled by the vm even in large numbers, and a couple of conditioned applyMovement/rotation.
I was referring to the visual complexity of the node: it’s a huge list of stuff to fill, it may throw people off. That’s why I need predefined values, which in turn requires specialized sockets.
I want to say that when I express my concern about performances, I do that on a perspective basis. I haven’t created big complex trees yet but the one I made, even with twenty nodes or so, have not yet show any sign of issues.
The only time when I see more than 1% in the profiler is when something goes horribly wrong and the network starts printing exceptions like crazy. I’m even starting to think that there is a bug in the computations of the built-in profiler because in standalone mode most of the time I see zero.
I also have to say that the only time I really had any performance problem with python scripting and blender was when I had the idea of making an abstract particle system using python. That really didnt’ work.

29

yeah you will need some of hg1’s new magic to make a proper particle system,
Drawing into the viewport.

30

man that reminds me on the flowgraph from cryengine… I loved it so much as a kid

31

Updated to version 0.0.7. Fixing bugs, more nodes. Lots of nodes. Camera Pick, Mouse Pick, Ray Pick, Install Subtree, Play Action, Action Status, Mouse Cursor, Dynamic Object Controller (for FPS and TPS characters), Python Module and I forgot what else.
I did a test for a “real” door, I’ve posted the video.
I’m not 100% sure it’s the only way to write a door with the available nodes - I’ve started loosing track of them - but it’s way too complicate for such a common action. I think I have almost all basic nodes, now I need the useful ones.

32

Toggle property should be a ‘end node’ like the property actuator

Use this to toggle a bool in the door,
Have the bool handle the door operations, dividing activation from function?

This always made the most sense to me.

33

I could subdivide the logic in two or more trees but that would only mask what remains a “statement” too complex for a quite common task. Basically everything that can open and close needs that tree.
The good news is that once defined, a tree can be simply applied to any other object by pressing a button. With a “minor” limitation, they can also be applied to objects at runtime.
Anyways I’m adding a “Open/Close Action” to the list of nodes to add.

34

for doors I actually keep the activation logic in the player, none of the activation logic/toggle is in the door,

this way you can deal with pick up items, pressing buttons, initiating ladders etc.

this way the player just presses interact, and it decides it it can toggle(the player)
setting the bool = True then moves the door (I use a property + a rotation or a action)
(if your looking at a button etc)

not sure if this is best for all, but I have found it very handy.
Like having no logic in the pick up items, just a property and a physics bound,
instead of having collision sensors in each pick up etc.


ray = own.castRay(End,Start,0,'Interact',0,0,0)
if ray[0]:
   if 'Weapon' in ray[0]:
       #Do weapon stuff
   if 'Button' in ray[0]:
       #Do button stuff
   if 'ladder' in ray[0]:
       # Do ladder stuff
   if 'PickUp' in ray[0]:
       #Do pick up stuff

using some sort of logic starting with a raycast, could you do something similar?(in your game logic nodes?)

35

Yap, there is a ray pick node, a camera pick node and a mouse pick node, they all aim stuff and report if something has been hit, the object, the point and the normal. I’ll make an example video - it is useful to test stuff, I need to test things a lot.

36

can you do

Ray-Pick ---------if property in hitobject-------subtract X from property

or

Ray-Pick----------if property2 in hitObject--------store property target as hitObject

??

37

Formally, yes. If you can do it in a python script, then the answer is always yes. In this case it just happens that the basic nodes I’ve added can express that logic statement.

http://www.tukano.it/images/rayhitlogic.jpg
http://www.tukano.it/images/rayhitlogic.jpg1133×686 144 KB

I say formally because I didn’t test this thing but I suspect that the GameObject Game Property parameter will raise a null pointer exception because I forgot to add a check in the code. Also things might be a little difference because I think (I wrote the system, but that doesn’t imply that I also fully understand it :D) that Ray Pick returns “True” in Has Result for as long as the ray picks a target and not just the first time it does so, while the statement seems to imply that the evaluation should happen only once per state change.
That reminds me to add a general “Pulse” Condition node, it will solve this kind of uncertainty.

38

I wrote a temporary tutorial for the door thing that should help understand how the system works. A proper user manual will some day appear, right now things are still changing as I speak.

door tutorial

39

Updated to version 0.0.9. Fixed bugs, updated the action node with some output conditions, added a switch parameter, fixed bugs.
On the code side, I have to add nav mesh stuff (no idea how yet), 3D sound (no idea how yet), end game, load game, random generator, distance triggers and nothing else that I can think of.
After that, optimizations.
On the usability side, I’ll have to write a list of nodes and properties of each one and the node-cell development manual.

40

Nice work!