Rob’s point about the use of $ is a good one. You really should avoid using it.
$ refers to the currently selected object. But which object that is, particularly, can change unexpectedly. It can change either through user action, intentionally through your script, or as an unintentional side-effect of your script. Would the change be obvious in any of these cases? No! Yikes!
It’s best to identify, right away, the object you’ll be operating upon and assign it to a proper variable. Then, any changes to the contents of that variable will have to be made explicitly, so you (and anyone reading your code) will know when the change happens.
You can use $ in the script listener as you’re testing things out, but it’s scary otherwise. Avoid!
For that matter, “selection” is just like $. I don’t like to see it except when you copy its contents to a new array that is under your control.
Say you’ve got 40 objects selected when you execute this:
for s in selection do
(
[INDENT]select s
)[/INDENT]
How many iterations do you think you’ll do? 40? Nope. 1. Because selection is dynamic, after the first run-through the loop, the selection only contains one object, and you’ve already iterated over it.
Of course, no one would use this specific example. But what if you call a function in the middle of your loop that you don’t expect to affect the selection, but does? Execution ends before you expect, without all your objects getting processed. Or, and this could be worse, an object you didn’t expect to get processed, does!
I kind of agree with Rob about the use of ResetPivot et al. To clarify his point, let’s look at a simpler example.
Given two integers, a and b, what would you rather see in your script?
c = a + b
[INDENT]-or-
c = AddOperatorForInts a b[/INDENT]
Let’s say AddOperatorForInts actually returns a + b, but you don’t know that unless you look it up in the docs. So the second example does exactly the same thing as the first, but obfuscates your code. Not so great.
Rob’s arguing that ResetPivot and CenterPivot are essentially equivalent to AddOperatorForInts, and that you ought to just do the math in situ.
I think the code reads just fine with ResetPivot in there, but I also see Rob’s point. My opinion hinges on his use of the word “relatively” in “relatively simple mathematical concepts.” Ultimately it’s relative to you, your skill level, the skill level of the people you expect to inherit your work, and your own take on the issue. If reading the math is more confusing than reading ResetPivot, stick with what you have.
In many cases, breaking things down into steps that take more lines of code is actually a better coding practice. Not only will you have more opportunities to check your assumptions as you debug, catching more mistakes, but your train of thought will be easier to follow for others reading the code. Unless performance is an indicator, I’d prefer code that breaks things down into smaller steps and explains itself along the way.
I do get the inkling that we need to focus a little more on helping you with your specific issue, though. What exactly is the code you tried to copy/paste that didn’t work?