probably my school is too old but the text representation looks for me more intuitive, simple, dynamic, powerful, and compact than the graphical one.
PS. I think that Visual MAXScript is most useless tool in MAX, and I’ve never used it in my max script development,
Here’s a fun looking case statement:
denisT: probably my school is too old but the text representation looks for me more intuitive, simple, dynamic, powerful, and compact than the graphical one.
PS. I think that Visual MAXScript is most useless tool in MAX, and I’ve never used it in my max script development,
@Denis: much thanks for all the help you have given me and others! I agree that the text representation is much better in all ways… that’s what I’m used to… however I think there are different ways to interact with and develop code beyond typing. I usually hate writing case statements due to my head not being able to remember the proper syntax, but building the one above felt liberating and somewhat enjoyable. I think it’s because there’s no formal syntax that I have to obey when constructing these nodes. And, in a way, the nodes separate the user from the language being written. I’m sure a node could be written to interpret a nodeset as maxscript, or C#, or python… maybe even CIL code. It’s just writing strings to a file based on objects cas. If I can build the nodes to work with any language, then any nodeset should be able to ‘compile’ to any file type. And since nodes can be written/saved/loaded as simple .ms files, this allows the community to start developing their own custom nodes. I value your opinion and direction very highly denisT!
Here’s one more for today. Top is zoomed in on the try(). Bottom is zoomed out to show the whole try()catch().
This assumes nodesets can be grouped and customized. Now imagine traversing through a script by zooming in and out of circles… instead of scrolling up and down. And this is all still in xyz space, so you could start stacking them, and separating them by layers, since they are after all both sceneNodes and code.
If I don’t like Visual MAXScript editor it doesn’t mean that I don’t wish any good one. I use Visual UI Editors in many other places. I just don’t like the MAX’s one.
Just started messing with your script, pretty cool stuff :).
I do find it a little … unintuitive, to scroll through/pick something in the menu, and instantly have it create it in the viewport. It would be better if you could possibly have drag/drop to create a new UI Node. Or even choose it in the list, and press a button to create it.
Here is progress on the script. I’m preparing version 1.1 to be released, which will have value nodes that can be linked to rollout elements based on a padding/proximity value (grey circle).
Notice the 1st dropdown? This allows me to organize objects into categories, paving the way for all kinds of awesome nodes. Once the values can be linked up and properly written as code, I’m going to extract the objects build parameters and write parameters to external .ms files – effectively turning the .ms file into a node that can be built and written based on it’s contents.
This does three major things:
- opens up the nodes to be customized by max users.
- paves the way for the VMeditor to write nodesets as a single node (.ms file).
- because of (2) allows the user to simplify and navigate scripts using custom nodes.
@Kickflipkid687: Thanks man!
Let me explain my reasoning behind putting the nodes in a drop down: this allows me to group them into categories by adding another dropdown above it. So, now a user can select UI Elements or Code from the categories, then select what they’d like to create from the ‘create’ dropdown.
Now let me address why there isn’t a ‘confirm’ or ‘create’ button. This approach is specifically tailored to working quickly, and assumes that when you select something – you want it created. Nothing annoys me more than Windows Vista or Windows 7 asking me ‘are you sure you want to do that?’ with a popup, or forcing me to confirm. So it’s my attempt at trying to address the dichotomy that exists within UI today: un-necessary confirmations. I’m also aiming to eliminate the steps the user has to take, which also simplifies learning how the script works.
I want drag and drop. However, drag and drop would have to be done in dotNet (which I don’t know), and would require some clever code to determine where on the depthAxis (z axis in screen mode) the node would be ‘dragged’ to. You also have to address having a ‘library’ of nodes (icons) that take up screen real estate. I did some concepts along this route, but ultimately couldn’t implement them. I considered learning Helium to write the nodes in, but I don’t want to have to deal with the additional install, and I didn’t have visual control over the nodes in the manner that I wanted.
So, I hope you don’t read that as “I disagree, you’re wrong”, but rather as “Good thoughts, there is a lot to be considered while creating this, please keep contributing your feedback”. I’d much prefer to have an elegant drag and drop method.
Yeah, that makes sense. I also hate the confirms as well, so it’s not bad. Dotnet isn’t too hard to learn, it’s a little differen’t/confusing maybe at first, but not too bad.
But you are right in that choosing what want, and having it created right then is a good method.
I could take a look into drag/drop of stuff into the viewport. For this project and just because it might be useful for me or others in the future. So I’ll poke around and see if I can’t get something working.
As far as the zdepth , I think just having them at the origin would be best. So if everything is always at the origin, it should all be good. You can probably also lock the axis to only allow the user to move then in x,y and not back/forward.
There might be a way to use the GW Drawing methods in max as well, instead of 3D Objects. So its then overlayed and not an actual node. But that might not be as… user friendly, I would have to look into that.
Edit:
http://forums.cgsociety.org/showthread.php?f=98&t=828462&highlight=drag+drop
This post has some interesting stuff. Seems like you might be able to combine some of this, so u could drag/drop from a list, and copy the name, and if it’s “button”, then create a button at the mouse.pos. Then you can drag around the button to place it and click on build UI or something.
K, so I got this
http://dl.dropbox.com/u/6895456/DragDropTest.avi
But I just learned of LoneRobots method for drag/dropping via Dotnet. So I got it now where I can drag/drop from a DialogMenu, and it creates a box. So now I just gotta see if it can do the same, but with a dropdown list. Just get the arg/value u selected, and if its like Button, then make a rectangle.
Garrick, this is awesomely inspiring stuff! :applause:
Massive respects and best of luck with it in the future!
@Kickflipkid687: Nice post! I’ll be digging thru that and learning more about potential drag and drop solutions.
Please feel free to put together a drag and drop script. Here’s my thoughts on how I see that working: the drag and drop library would load all the .ms files (with corresponding .png icons) from a folder and display them visually in a way that doesn’t take up too much space. This may be accomplished with scrollbars, a paging system, dynamically scaling icons (think Adobe Bridge), or however. It’s important that the library be able to load as many .ms and .pngs as the folders contain, so users can add as many nodes as they’d like to the library folders. If there is a way to do it with .jpgs or another file type, that may be better. I suggest .pngs cause of transparency.