@Kickflipkid687: Nice! Just saw your .avi! I like that functionality. I’d like to see dragging a button into the viewport and building a box. If that’s a solid route to go, then we may just have drag and drop after all!
@elT: Thanks man! I hope Adsk realizes what potential an interface like this has.
Yeah, having something like buttons with Images as their background, for each node would be easy enough to do. It would just read each image and ms file in, on rollout open, and fill the thumbnail array with those. I already have that code working for another tool I made. But it collects objects bitmaps from their materials. But I could easily switch it to collect images from a folder.
One of my biggest concerns is being able to actually develop useable code using nodes.
So, to see how this design I’ve described might ‘play-out’ I’ve attempted to build the VMeditor code inside of the latest flowCode node concept designs. I’ve gotta say, building the node sets was pretty fun and fast… and zooming in and out of the code feels like I’m writing atoms together under a microscope. Weird, but kinda ‘natural’. Here is lots of images:
First, a zoomed out view of the nodeset.
Here’s the input(bottom) and output(top) links for the rollout.
Here’s the 4 main functions. I didn’t realize there were four until I began organizing the code. I color coded them as well. This will help later on
Above is a zoomed in view on the rollout, showing how lines can link UI elements to nodesets.
Below is a custom nodeset describing the compileScriptsButton on pressed event. I envision being able to ‘open’ these custom nodes and drill down to a more granular view of the code.
Here is a drill down into the createDD selected i event. Here’s where the colors come into play, as I can easily see which case evaluates to which of the rollout main functions. In this case, it’s handling 7 UI elements, 3 values, and 1 custom function build (the VME editor – in purple).
Here’s the timer tick event that calls updateOffsets (one of the rollouts main fuctions, in blue).
I’ve shown this to some friends and they all say it looks like bacteria/atoms.
More coming soon.
@Kickflipkid687: That’s it man! Let’s plan to build that kind of functionality into the script.
That is awesome!!!
Ok, so I took my other code and got this working.
Right now it takes the images in a folder, looks for .png images, and reads them in and sets their size in that rollout, based on their actual size bitmap size. Then, internally it sets the buttons name(s) in the rollout, based on their filename, so Button or checkbutton, ect.
After that, when you drag/drop the button into the viewport, it reads that buttons name, and sets the text to be that same name.
That’s all the basic functions covered! That was fast man!
How do you see the integration into the current script happening?
I think the script needs more work before it can handle loading the .ms files.
I’d like to get linking working before extracting the UI elements and nodes to .ms files.
However, if you’d like to integrate it into the current script that would interesting to see, because it would give us the ability to start trouble shooting and expanding upon the drag and drop idea.
It’s your call.
I’ll be working as fast as I can to get the linking and writing of values done.
Well I figured I’d give u the .ms script, so u can implement it if you want. Or I could tinker around with it more and figure out a better setup.
What might be better is, having a drop down, for categories, then below that is a sidescrolling window,
showing all the thumbs of the buttons/ect you can work with.
So you would switch to UI Elements, and it would update the thumbs with those button images, or if you switched to operators, it would show thumbs of your otther nodes, like multiplication and so forth.
@DenisT: I’ve been thinking more about how to bridge the code and node worlds. Here is a concept of ‘opening a custom node’ (a .ms file represented as a node):
The first comment has a typo in it, it should read “–this is the code view of the writeSource node”.
The buttons on the bottom represent save and cancel, just a quick way to access the real code, while still retaining the ability to traverse the script as nodesets. I’m sure something in DotNet could be made even better than this example (which was made in about 20 seconds using VMEv1).
Maybe we could drag and drop nodes into this code snippet popup, to add nodes directly into actual code? Hmm…
Yeah, you could probably store the code in the nodes UserDefined properties possibly… then with drag/drop, collect that info and paste it into the window… ?