I think a lot of people would be happier if the menu items were in a submenu, rather than directly in the Plugins menu. It's hard to know (especially when you have a lot of Plugins items) what is for Demeter and what is for other plugins.
In lieu of that -- or, even better, in addition to that, have a menu-generating system that is Organizer.rb compatible.
Standard ruby conversion methods include (but are not limited to):
.to_a - convert to an array
.to_i - convert to an integer
.to_f - convert to a float
.to_s - convert to string
Though standard ruby, they may not be applicable to all data types. SU adds more .to_n methods:
.to_feet - convert a number of inches to feet
.to_yard - convert a number of inches to yards
.to_mile - convert a number of inches to miles
.to_m - convert a number of inches to meters
.to_cm - convert a number of inches to centimeters
.to_mm - convert a number of inches to millimeters
.to_km - convert a number of inches to kilometers
.feet - convert a number of feet to inches
.yard - convert a number of yards to inches
.mile - convert a number of miles to inches
.m - convert a number of meters to inches
.cm - convert a number of cm to inches
.mm - convert a number of mm to inches
.km - convert a number of km to inches
There are also .inch and .to_inch methods, but since SU internal units are inches, these are almost never used (but are included, I think, for consistency).
Clark,
@unknownuser said:
The reason I'm using the selection is that it's easy to add all the entities to it. There's a sel.add that doesn't care what kind of thing I'm adding.
True, but .erase! does care what you're erasing (as you discovered), so you're still in the same boat with type checking. In fact, that's really the bottom line: check everything and assume nothing.
It's a hassle, but it's necessary, because inevitably someone will come along and provide unexpected input, and things will error out.
Regards, and happy coding!
Clark,
Yes, as you erase edges that bound faces, the face is removed from the selection automatically (since it no longer exists), and the objects' indices are shifted accordingly.
Given sel=model.selection followed by sel.each{|e| e.erase!}:
The script erases sel[0], an edge. That edge bounded a face at sel[1]. This shifts the object at sel[2] to sel[0], which is then ignored because the .each loop has already finished working on sel[0] and moved on to sel[1].
Furthermore, faces aren't the only culprits. Erasing anything could cause the next entity to be shifted to its index location, thus you can miss about 1/2 of the entities on any given pass of selection.each.
Better to add the selection entities to an array and cycle through the array rather than rely on selection.each
Clark,
Does the error line correspond to the erase! command? Or is it pointing to a different portion of your code?
Rob,
To export to the types you specified, just change the stuff in parentheses after the %w at the beginning - something like
%w(3ds dwg dae obj)......
and leave the rest of the code intact.
Using a dot-slash ( ./ ) puts the export files in the same folder as the original file (assumes the file has been saved somewhere), which might be more convenient.
Regardless, nice one-line coding 
Too bad this wasn't issued specifically as a ruby challenge item...
Brad,
Way to ask the question! I made the (incorrect) assumption that this was curved construction geometry (which I still think would be a great addition to SU).
As a standalone object, no. As a group of separate construction line segments, yes.
I think this is a good idea for SU7 to handle internally (hint hint, Brad).
Please explain "bit per minute". How should this script work?
That was a great explanation!
When I have time, I want to fix the rotational speed issue, but with our first baby due in 4 weeks, time is at a premium (and likely will be, for a while). When it does get fixed (and I do intend to fix it), I'll post the update notice here and on Smustard's news section.
I'll also try to get a sample worked up that shows before/after movies of PageSmoother.
Do you really have GSU6 installed under "@Last Software" ??
That would be my first guess.
Unfortunately, no. It's an OpenGL issue internal to SketchUp. I've been in contact with Google about this in the past, and they said it's a very involved issue to make happen.
I don't mind as long as there's a link
(http://www.smustard.com/script/FloatTolerance)
You would need the instance of the submenu. I don't know of a way to get the instance after the fact, but there might be something undocumented somewhere...
I've actually created this for my own use. I could adapt it for you.
EDIT: linetool.rb should be in your Plugins/Examples subfolder
It sounds like you want the instances to remain where they are, but the axes are changed. Is that correct?
Okay, I didn't remember that copy to nodes didn't rotate as it went. I'll take a look at that sometime (hopefully soon).
The script should do the railroad track example already. If it doesn't, make sure you have the latest version (and if you got it from Smustard and not from the SU Ruby forum, then you do), and if you still have problems, let me know.
