Visual Scripting Feature?

#41 How about the system is simplified to some very specific game mechanics/effects and the GUI only creates a script for it but after that you have to edit it yourself?

I might be thinking too simple but I can see a basic version for something specific working.

Example:

We can have a system made for triggers and using the workflow we can have the trigger do set things on enter/exit.

Then we have to have the scripting style split up into categories for specific function.

So for example we have a category for Lights/effects Instead of asking the user where to place the light it places the light in the world then the user moves it to where it need to be then the scripting part lets us select what we want to do with it which would be all the functions we can do for the light that shows up in the editor already (on, off, blink, colour etc)

If we bring it to a more simpler form of when this happens, do this with this object and we use the windows already int he editor for that object on what to do then add that to the script.

Trigger
           |
      ------------
     |            |
   Player        GUI
     |            |
  Set Skin   Flash Red Fade

#42 I would also like a system like this mainly for opening doors with triggers and such!

I would also consider throwing a small donation or two your way if progress is made :)

#43 Robert (or anyone else who is interested)
Would you be interested in some collaboration then? Like I said earlier, I have your issue 2) (logical flow etc.) mostly figured out and partly implemented, and I don't see any definite reason why the gui would have to be directly integrated to torque. I would likely just need someone to guide me around the engine sources and maybe write some simple access code. I can get by on my own too, but it will take ten times longer.

The issue 1) I would solve by creating a generic api access system that can generate new IO nodes from existing code. Name and api changes will then only break things locally in the graphs and the changes can be fixed in batches. I've already been thinking about that for a while, since my own system eventually has to deal with different apis in multiple languages. Robust type system helps a lot here too. To make things easier for end users there probably has to be some kind of manually constructed filtering system to show just the most relevant functions, but I doubt that will cause that much work in the end.

Currently my system compiles only to Python and OpenCL, but it's not a big stretch to also enable C++ and Torquescript. Initially compilation could be done statically and linked at runtime, but eventually one could consider some libjit or clang/LLVM -based rig to compile the code.

#44 Why reinventing the wheel when you can build upon something ;)

recentlly Verve was released under the MIT License.
Verve itself is a cinematic tool with some more things that actually enable one todo some things with ease
such as opening doors/ animating those in the game and setting paths for ai to follow.

The current status of it - its broken but on the first look it seems not to be that hard to fix.

You can read more about Verve here
www.garagegames.com/community/blogs/view/22548

#45 @Antton:
what kind of code are you needing? if its hooks into the language, WLE may be able to help you with something like that.

Paul

#46 @Antton,

What would you need to move forward? I've written a static code parser for T3D which extracts all the script related information from the C++, right now I convert it to C#.

It can be easily modified to generate meta-data etc. I also have a pretty solid understanding of how the stock console works. Feel free to hit me up. VGee@winterleafentertainment.com

#47 Jolinar right, but if someone does decide to do a visual scripting editor. I think it should handle the games logical mentioned above, it should also allow the user visual add custom material to various things (particles, models, etc...)
Lukas is working on a visual graph format editor (I think). github.com/LogicalError/Graph Maybe a good place to start..

#48 well @Kory
that doesnt mean that others are not working on something along those lines aswell ;) Greed^^

besides there is a big difference between a pay to use engine
and a free to use under mit engine

#49 @Kory just for good measure, the Graph library was made by LogicalError, not me. And it's only the UI part. It's a great library for getting a jumpstart with the UI, and I've found that it is almost 100% Mono compliant. Only a small issue with some strange '@' on a variable name somewhere, I can recommend it if you are doing node-based.. Anything really..

#50 @WinterLeaf folks
It would be bloody fantastic if you could help me out. It does indeed just embed itself into the program and the rest of the code can't tell it apart from any other library. Since that also detaches it from the node editor, one could optionally autogenerate simple guis for Torque side to get convenient real time controls over the program.

What I would need. Very briefly:
First I would need some way to extract name and type information from object classes and functions (inputs, outputs, class members). The editor will use the info for initializing IO nodes, type checking and building representations of objects. Then I likely need a way to port snapshots of the scene graph (or parts of it) to Blender. Simple Json or XML dump will probably be enough. Then the runtime code obviously needs to access and modify the scene data, but I'm actually not sure if this requires any extra abstractions. The direct IO nodes might be enough.

Finally there needs to be a central system that handles the execution, linking and communication with the engine. That is the most uncertain thing at the moment, so I don't want to speculate how it should work before digging deeper into the source.

I think I better draw some diagrams before getting to more details. I have a habit of writing pages' worth of text about simple things :).

Big disclaimer though:
Since you are a business, you presumably want to use this for practical purposes reasonably soon. I should be very clear that this is not yet stable, production ready system, and likely won't become such for quite some time. Although I'm very confident that things will work the way I'm imagining now, everything is still considered experimental and can change dramatically (and therefore take more time) in future incarnations.

But for purposes of moving forward, I'm all for getting the basics running inside Torque or whichever version of the engine you are working on.

#51 Antton,
Yes if you can do it, please. I'm sure the community could greatly benefit from it. Also would it just be used for material/shaders or is there a way to plug it in as a AI and game logic also?

Lukas, Yes you are right, but I'm still excited to see what you come up with. IMO the committee disbanded at a bad time. There are alot of good stuff coming out of the wood works.

#52 Kory
Anything that's programmable can be done, from shaders to AI to physics. Probably my biggest personal interest is everything procedural, like generated forests, terrains, cities and partly simulated animation like hair, cloth, particles, crowds and flocks. I won't have time to do all that, but I'm at least trying to enable others to produce such things.

On Blender's side I'll likely do a lot of things for procedural geometry, such as new primitives, new/better modifiers, polygon hair and other modeling tools. Everything can of course be ported to Torque as regular geometry. I've actually thought a bit about making a Blender-Torque pipeline tool based on this. Would be handy to do all the setup in Blender, port fully rigged characters in one swoop and have them behave identically to the originals.

I'll try to show something more concrete soonish. I just finished a simple hair simulation fully done with nodes. I'm now making a demo video and more comprehensive writeup of it.

#53 Antton,
Awesome! I can't wait to see, please keep us updated.

#54 So the video has taken a lot longer to produce than I though. Apparently I'm just really bad at voice-overs, and I initially made it way too technical and longwinded. Will post it when it's done.

But upon further consideration I'm taking a few steps back. I came to the awkward realization that Torque does not currently have fully working OpenGL or Linux support, which is bit of a deal breaker for me. I don't even know where I got the impression that it had those. This rather bothers me since I seem to really like everything else about Torque. It's also starting to looks like a decent cross-platform graphics framework is really all that I need at this point, so I'm falling back to Ogre for the time being.

If all goes well there, I might take another look at Torque, and even if I don't do it myself, I can help someone else write the glue code. Once I have things figured out, it should be fairly straight forward.

I may have jumped the gun a bit anyway. I probably should be doing a simple proof of concept implementation first before starting to work on any engine integration. I think it will be a lot easier to get started with just a graphics engine.


As a mad, hypothetical side note: Since I'm probably going to be abstracting away most of Ogre's api calls, it would be bloody interesting exercise to try to integrate that whole thing to Torque. If I do similar abstractions on both ends, my system would sit nicely in the middle of everything. Maintaining two world states might be quite slow and bulky though.

#55 try: github.com/LuisAntonRebollo/Torque3D/tree/dev_linux_opengl

#56 Ogre and Torque would be great. Same reason you use a physics library: offload the burden of maintenance onto someone else who's interested and invested in it.

As for the editor itself - why does it need access to the SceneGraph? I had the impression this would be a compile-to-Torquescript deal. In which case you build a nodegraph in an external (or internal) editor, hit 'save', and it generates a script that implements your graph.

If it were an internal editor,

Quote:how do I go about adding this to the "list" of selectable functions? It's a hefty practice that needs to be done.

then you could just call %obj.dump() and parse the list you get (you might need to create a new dump function that returns a string instead of echoing it, or something).

#57 Azaezel:
I'm aware of the ongoing OpenGL and Linux efforts. I just don't think they are quite ready for production yet. It's entirely possible that they will be by the time I've got this running, so I will take another look then, and maybe even contribute.

Daniel:

Quote:As for the editor itself - why does it need access to the SceneGraph? I had the impression this would be a compile-to-Torquescript deal. In which case you build a nodegraph in an external (or internal) editor, hit 'save', and it generates a script that implements your graph.

That's entirely correct. Strictly speaking it's not necessary. It's mostly a convenience thing, so the user can just drop in scene items with few clicks. Sometimes it may also be beneficial to "hardcode" static scene data into the executable code to avoid runtime queries.

#58 @Antton Tapani - Is there anyway I can get ahold of you. I would like to talk to you privately about something.

#59 Sure. I was gonna say PM, but apparently that doesn't exist here :). Email is probably the most convenient way. Here's a riddle to fool the robots.
firstname.lastname@gmail.com
(all lovercase)

#60 Hey Robert,

This would be a great feature. One of the best features in UDK when I used it a while back, hit the bullet and went open-source, was the visual scripting unit. If we could integrate triggers, cameras, some basic bool, char, etc. Just some basic stuff that is included in Kismet that implements some basic scripting. Also, you could use GMK's trigger system and such and just convert the UI to a visual scripting UI.