Can y'all try to bust my script for me?

I was looking for something like the rivet script from Maya for 3DStudio. I realize that there’s such a thing as the Attachment constraint, but the UI for it leaves a lot to be desired.

Long story short, I spent some time writing a script to handle making the attachment constraint play nicer. If any of you would like to comment/break it for me, I’d appreciate it. If you like it, feel free to use it.

I’m thinking of trying to replicate it in plugin format at some point, rather than going through the slower script interpreter… plus, I’m thinking some of the random crash/unknown exception stuff that happens now and then happens because I’m doing this in script.

p.s. I know other people have probably written something like this before, but I could not for the life of me find it.

I take pride in bustin scripts.

I don’t have Max anymore so I can’t run your script but your code looks pretty good.

That’s a nice thing to hear. Being completely self-taught, I’m always worried that I figured everything out either the wrong way, or the extremely hard way.

… though I’m honestly hoping someone will snap this thing like a twig and tell me “Why’d you do ‘x’? That’s the dumb way! Try ‘y’.”

Just a quick note in regards to return. You might already know this, however, “return” in Maxscript is really slow and is unneeded as you can just place the value to be returned as the last value in the function.

For more information, see,
MAXScript FAQ > How To Make It Faster > Do not use return, break, exit or continue

Jonathan, we’ve found in later versions of Max (2008+) that doesn’t make much of a difference and in fact return turned out faster than the alternative sometimes (for/while). At this point I’d hardly worry about it except if one were doing micro-optimizations.

Seth: Don’t get me wrong, some things drive me nuts (lack of use of local, the whitespacing/bracketing scheme, all code entirely in the UI), but at least you divided up yoru code pretty well, didn’t have globals, format instead of print, etc.

Yay! I still got taken down a peg! With respect to the “local” bit, I did use that up at the beginning, where necessary, and the scoping should take care of preventing any illegal access otherwise… Are you suggesting that I should use local on every variable, regardless?

Also, I picked up the bracketing habits from working in C# in Unity. You’re allowed to hate it, since it seems to be different for just about everyone. It’s just what I’m used to… unless you’re trying to tell me that there actually exists some standard I don’t know about.

And the code in the UI bit - I guess you’re just saying I should move all of that into functions to call from the UI instead of leaving it where it is… but what does this gain me? Cleanliness? Or performance?

[QUOTE=Rob Galanakis;12413]Jonathan, we’ve found in later versions of Max (2008+) that doesn’t make much of a difference and in fact return turned out faster than the alternative sometimes (for/while). At this point I’d hardly worry about it except if one were doing micro-optimizations.

Seth: Don’t get me wrong, some things drive me nuts (lack of use of local, the whitespacing/bracketing scheme, all code entirely in the UI), but at least you divided up yoru code pretty well, didn’t have globals, format instead of print, etc.[/QUOTE]

Ah, very interesting to hear.

That would be nice if that’s the case, would make reading scripts a lot easier. :): I’ll give that a try soon.

Yes. Otherwise I have no idea what scope a variable is defined in without checking any number of times up the chain (all the way into global scope or until the variable disappears), since Max has such loose scoping rules.

Also, I picked up the bracketing habits from working in C# in Unity. You’re allowed to hate it, since it seems to be different for just about everyone. It’s just what I’m used to… unless you’re trying to tell me that there actually exists some standard I don’t know about.

There isn’t.

And the code in the UI bit - I guess you’re just saying I should move all of that into functions to call from the UI instead of leaving it where it is… but what does this gain me? Cleanliness? Or performance?

It would gain you cleanliness if you were in a situation where you were writing reusable code. But as a dependency-free, single tool, it doesn’t matter.

I didn’t mean to knock you down a peg. The code was good. Some things just drive me nuts. It doesn’t mean it is because the code is bad.

I shall attempt to take this to heart. Thinking in terms of C/C++/C#, I figured this worked as is and made enough sense. I don’t recall having seen a lot of access modifiers on temporary variables within functions in a class. I suppose I could set temporary variables created in functions to local and leave it off of values passed in to make it quicker to visually figure out where data is coming from.

Ok… I can see this. I can’t see that there’s a lot that I could use from this specific tool that would be reusable, though, but it makes a lot of sense.

Oh, I’m not distraught in the least. This is really the first time I’ve written a tool that I’m willing to show anyone outside of my extremely small art team. I have aspirations of escaping here at some point, so I need to know how to perform as a tech artist and what would be expected of me. I was riding pretty high on having written this nice tool with a full UI, and so far it’s turned out to be fairly robust. Up until today, I thought I was the only person in the company who knew MaxScript (just found out I have an ex-tools writer from a local game studio), so I have to rely on people like you to call me an idiot if I’m ever going to learn anything. That’s the biggest reason I have for posting on here.

So, yeah… Knock me down, call me a dumb-ass, I’m fine with that so long as you make it a lesson as well, and show me how to do it better.

So, this has a couple updates. I put in functionality to make it automatically snap to the nearest vert as well as a spinner to control the size of the point helper. I also did some clean up with respect to what Rob brought up. I also found a small bug with click to place throwing an error when it was trying to tell you you weren’t clicking on something valid… ironic, isn’t it?

Thoughts?

So, I’ve had it shown to me that using complex-shaped rivets can break the script. A teapot, for example, as a rivet, projected in +y causes the raycast to intersect with the spout of the teapot, causing the rivet object to attempt to rivet to itself. I’ll have to filter the intersection results better.