[dead] Combinable logic framework

I was planning to say "Wow"…but i can't because my jaw just dropped…



Incredible work!

Thanks.



Now i'm writing the code writer. If it works, the program will save the worskspace to a java source code file. There are a couple of corner cases that should be handled before the 1.0 (like circular links or clashing names) and some visual improvements (like some sort of highlighting to see what is linked to what, i'm trying to think to something more than arrows that kinda suck when the document complexity grows, we'll see if i find something better or not) but an alpha version will see the light in days.

Effin amazing! This concept stands to add a whole new aspect to the jME project. No other open source game engine to my knowledge has anything like this; not many commercial engines has anything that really works.



Let me know when you’d like some programming illiterate to test this for you. Instructions required…



About the visual improvements, especially with regards to replacing arrows with something more aesthetically as well as structurally appealing, I would suggest you have a look at this website:

visualcomplexity.com | A visual exploration on mapping complex networks



I will be looking through several for more ideas, but here’s my favorite so far:

visualcomplexity.com | visual i/zer







Notice how it doesn’t get as messy as plain arrows even when the lines intersect. I find the combination of width, color and transparency very visually pleasing. To accentuate special relationships between blocks you could even put lines within lines, if you know what I mean. Like, upon seeing a thin red line within the ordinary thick purple one, you realize “ah right, this block receives that thing back after its done over there”. Hope that makes sense.

Well, i don’t know how clearer it is but the background-curved-transparent-thick connector looks cute.



Great! You warned me not to get you too excited about visuals, so I'll be brief:



The merging of two lines, like with Vector3f9 and right side of CopyLocalTrans6, looks a lot better than the bottom side of CopyLocalTrans6, which gets a little blurry and confusing. Is there an actual difference between the connection at the right vs the bottom that makes the visuals appear different?



One option you could try out could be thin borders on either side of the transparent lines, so that they're closed in. Ideally these borders should disappear when lines intersect, as that overlapping effect makes a lot of sense.

They really are separated lines. The reason why the yellow ones looks ad they do is because (well, first yellow has little contrast over white) the major axis of the region that contains the source and the destination are different and I use that axis to compute the control point of the quad curve that draws the connection.



Maybe a solution to harmonize the output bend could be to use a cubic curve (that has 2 control points), compute the second control point from the major axis and use a constant translation from the origin point as the source.



In all that, the good news is that it is in fact so simple to handle the drawing of stuff between elements of a graph that we could do whatever we like. While the transparent thick lines look good, "taking inspiration" (aka stealing) from a working app leaves a bitter taste in the mouth.



As soon as i finish the persistence layer maybe we could try to find something more original (and functional at the same time).



What really concerns me regarding the visual appearance is that the editor will be packed as a JMP plugin so the very cool and smart look has to blend with the rest of the UI, otherwise the user will feel it as something strange.

And here we go







A couple of dimensions to adjust, few “internal” tests and it is ready to be… tested

Ok, more than a few internal tests… it’s working.



youtube



In the test of the revised logic program i’m pressing 0 to activate/deactivate the cube movement (i have to learn video editing…)



I need to write a few more default conditions/reactions but the program accepts xml definitions for that so it is just a matter of thinking what could be generically useful and to draw an icon that somewhat resembles the meaning of the condition/reaction.

That is very impressive!

Now available in the jMP contributions update center :wink:

Here's something for inspiration:

http://static.sc2mapster.com/content/attachments/4/336/sc1war3sc2.jpg

This is the trigger system from the blizzard RTS games.

Replaced the list to trees, so that conditions and reactions are grouped in the UI (double click on a group to expand it of course).



I wrote a little manual to explain the “logic” of the logic, available here



vpi manual part 1, googledoc

vpi manual part 2, googledoc

vpi manual part 3, googledoc



The next move is to add more conditions/reactions.

The next important move it to allow the editor to load externally defined packs of conditions/reactions/parameters.

The next very important move is to document the process of using vpi in a JMP project (a video walk through like the last one but with text hints to explain what happens).



Here the main problem is to make the editor aware of libraries used for the active JMP-Java project in JMP-Netbeans. More soon.

pgi said:

Here the main problem is to make the editor aware of libraries used for the active JMP-Java project in JMP-Netbeans. More soon.

Its pretty easy getting the project when opening a file from the assets folder, I prepared a way to reach back to the project that the file is in. Import "jMonkeyPlatform Core" as a library and use "AssetDataObject" as the base class for your file types DataObject. When loaded from the assets folder (important!), you can get the ProjectAssetManager (and thus the project) via ProjectAssetManager manager= dataObject.getLookup().lookup(ProjectAssetManager.class);

I'd generally suggest using the assets folder for the vpi files, its easier to leave them out later as there will be more advanced support for "development" and "release" assets. Right now one can already exclude certain file type. I guess the vpi files wont be needed later in the game as the plugin creates classes?

Cheers,
Normen

I have a little problem using JMP to develop plugins, something related to an harness thing. The “raw” netbeans 6.9 doesn’t have it so i use this: usually i prefer not to deal with language/platform/library/runtime/tools problems, i consider them unnecessary distractions.



I’ve packed important steps 1 and 2 in step 0, which is build the editor to create tokens for the editor. The editor will create xml descriptors for condition/reaction/trigger stuff and those descriptors will be loaded in the vpi editor.



This is the (rough) prototype of the sub-editor ui:







The user will have to create “active regions” or slots in that image by basically drawing rectangular regions on top of the underlying icons. Each rectangle will have the properties required to identify a “slot” in the vpi editor (a name, an index and a list of type names identifying the parameter’s type that the slot will accept)



Here the user is not who uses the editor to create a logic class for his game but the developer who wants to use the vpi system to create conditions and reactions for a particular library.



The ultimate goal is to be able to extend the elements displayed, linked and packed by the vpi editor without having to deal with the vpi library (so the only constraint will be the bricklogic framework).

Did you install the "NetBeans Platform Development" plugin in jMP before opening the project?

Otherwise the "harness thing" can be solved by pointing the project at the folders in a NetBeans 6.9 installation in nbproject/private/platform-private.properties, add two lines:



nbplatform.default.netbeans.dest.dir=/mydir/NetBeans

nbplatform.default.harness.dir=/mydir/NetBeans/harness



What do you mean libraries are distractions? You also use Swing instead of painting all info on the screen manually, so for bigger projects it makes sense to have an extended library like the NetBeans platform for functions like inter-software communication etc, no?



Cheers,

Normen

I didn't said that libraries are a distraction, i said that library problems are. Maybe not a correct English expression, let's try with "problems met when using a library".



If the way i can use swing ever pose a problem to the project i'm writing i replace it with a different library. If i can't find the alternative library, i choose between deal with the problem or writing a replacement from scratch. Of the two i choose what takes less time.



For jmp on netbeans what i think is that it has been a good choice not because it makes sense in a generic way but because rewriting from scratch what the netbeans platform already does, and it is useful for JMP, would require more time than dealing with the problems that the platform library may pose. This doesn't mean that i consider the netbeans platform a particularly good piece of software (in fact i could actually be jailed for publicly saying what i think of it) but it saves time, which is a very precious resource.

Sorry for 'dropping' into this discussion, I hope I don't distract anyone here.



Well, isn't there a 'Palette' window in Netbeans? I do think, it would be useful to use this module.

So the Logic Bricks etc. can be drag&dropped from the Palette.



This would integrate your plug-in better into the Netbeans Platform.



Just an idea I was thinking of when I saw your ui.



Keep up the great work!



Cheers,

Tim

I had the same idea but, unfortunately, the dnd system used by the tool isn't applicable to the netbeans ui.



Well, being a swing application that isn't properly true but I'm pretty sure that doing the same thing with the netbeans api would require mixing bat wings, frog eyes and dragon scales in the cauldron of a witch. I could deal with bat wings and dragon scales but the frog eyes freak me out.

Epic reply!  :smiley:

This project won’t be developed any further.