@numbthumb said:

What about the Offset tool?

If the legs happen to be different widths, Offset won't do the job. Plus, it won't hit the "end" edges, as it will be offset from them as well (if you offset from a face).

@j_forrester said:

I was wondering if there was a Plugin available as shown below. I often have to make spines in this way (manually) to perform copying of objects along a spline, could also be handy for midpoints along a top of a building for more complex roof forms. In essence it's very simple, but not sure how simple it would be to write.

It's not an impossible request, but it is slightly more complicated than it seems, since knowing the "end" edges is essential to a successful result. Either a good algorithm or a tool that requests specific necessary input would take care of it.

It seems there were some roof tools written in the past that might be modified to do what you need.

Just a general note: if you get something from Smustard and you can't get it to work, please contact us - we want to help you get it working, and we reply to all requests for help. I mention it since it seems most of the concerns in this thread (that mention specific plugins) deal with plugins obtained from Smustard.

@flyashy said:

Now i searched the forum and found out about the Organizer.rb by Rick W, but that script does not organize the context menu or am I wrong in that assumption?

It's a complicated answer.

The auto-editor built into Organizer does not change any context menu items. However, I think Organizer could possibly be tricked into organizing the context menu if authors coded their plugins correctly (or if end-users correctly modified existing context-menu-using scripts, but always have a backup in case you break something). I'll try to do some testing next week and report back with some results, but here's what I suspect might work:

unless file_loaded?(__FILE__)
  file_loaded(__FILE__)
  UI.add_context_menu_handler do |menu|
    if $submenu
      unless $context_submenu && $context_submenu[0] == $submenu
        submenu = menu.add_submenu($submenu)
        $context_submenu = [$submenu, submenu]
      end
      submenu.add_item("menu item name") { action }
    else
      menu.add_item("menu item name") { action }
    end
  end
end

It's just a first blush, but anyone (with Organizer) could test the theory.

Did you try CameraLines? If it doesn't do what you want, let me know and I'll see if either there's something else that already does what you want, or if I can mod CameraLines to do what you want.

@kwistenbiebel said:

Hahaha....Best Plugin ever.
Does it come with a toolbar?

Congratulations!

Thanks! No, no toolbar - but the UI is rather nice

@chris fullmer said:

Another thought on this script snippet Rick, be careful not to instantiate a new Family class object inside an infitnite loop accidentally. The results could be - catastrophic

Too true. I'd have to come up with some fantastic other rubies to sell on Smustard to pay for than one.

And thanks everyone for the kind comments and wishes - they are truly appreciated. I am glad I'm able to share this blessed moment with my SketchUp family.

class Family
  def add_daughter(name,date,weight,length,comments)
  end
end

Family.add_daughter("Abigail Grace","2009-11-25","7lbs 4oz","19.5 inches","Mother and daughter doing fine")

The most common reason for a bounded region not closing with a face is that there is a small, nearly invisible (until you zoom in) edge sticking out into the plane of the face you want to create. Once that edge is erased, MakeFaces (or overdrawing a bounding edge) will create the face. StrayLines can help with the task of getting rid of those edges.

@thomthom said:

@honoluludesktop said:

if e.typename == "ComponentInstance"

.typename is slow - very slow.
.is_a? is much quicker.
if e.is_a?(Sketchup::ComponentInstance)

I think I remember reading that
e.instance_of? Sketchup::ComponentInstance
is even faster.

@thomthom said:

You could scan the whole model, but that would be very inefficient. looping through model.definitions and getting the instances for each definition is the fastest and most efficient way to get to all the model's instances.

I concur. While recursion is elegant from a coding standpoint, it's grossly inefficient and prone to crashing SU. Best to find what you're looking for in the definitions.instances.

Have you tried SceneExporter, either to do what you want, or as an example of how it could be done? The Pro version will hopefully have the Save dialog working soon.

We did a similar split at Smustard - we have the Plugins forum for the user issues and the SketchUp Ruby forum for the developer issues.

@thomthom said:

Think there was a plugin that ensured the Select tool was activated upon opening or creating new models using that event....

@chris fullmer said:

And yes, someone did write a startup tool script....I don't recall who or what it was called exactly though.

Perhaps you were thinking of SelectAtStartup by yours truly

It used observers to check for SU launch, file load, and new file actions to ensure that the Select tool was the default tool any time the active model changed.

On the odd chance that your script is loaded before any other script that does require 'sketchup.rb', and your script uses any methods defined by 'sketchup.rb', your script will fail to load. This is most commonly seen if you use file_loaded?(file) or file_loaded(file) at the end of your script.

A sure-fire example would be if a user new to plugins happened to download a script that did not require 'sketchup.rb' but did use one of the 'sketchup.rb' methods. Having no other .rb files in their plugins folder, they would get a load error straight away, complain to you, and you'd end up putting it in anyway.

Not that this particular scenario has ever happened (well, not more than a few times, anyway - I know I've read about that scenario, I think on the original SU Ruby forum).

Originally posted on the Smustard forum:

Be careful when using string.to_l to convert text to unit length. Windows users in countries that use "," for decimal separation will likely have regional settings active for their OS, and Ruby is dependent on those regional settings. For the US, "23.563m".to_l will work fine, but in those locales, it will fail. Conversely, "23,563m".to_l will work on their machines, but will fail where "." is used for decimal separation.

A simple begin/rescue/end can set a class or instance variable for handling the proper notation convention. I may try to code this into a separate class.

@fletch said:

Something simple like exporting the images to a specified file doesn't seem like it would be difficult to do for a smart guy like yourself.

Fletch,

I'm embarrassed to say that this specific request slipped my memory. I use this plugin all the time myself, and occasionally think about it, but I've always been under the gun when I use it and think about it, then forget due to the pressures of my day job, and don't think about it when I might have a few minutes to spare. But no more. My intent is to have it done this weekend (along with the Mac version of CameraControls).

Question for you (all): do you want to always be prompted for a save location, or just have it as an option (like the other options)?

@pixero said:

Surely such a plugin already exists?
I've tried Rick W's Group by Texture but I'm having problems since it only groups some of the Materials.

The older version required repeated attempts due to nesting of G/C's. Those problems were supposed to have been fixed in the latest (1.1) version.

@tig said:

This along awaited update of RickW's tool CopyAlongPath - to rotate as it copies... I'm do some other stuff that will involve an algorithm that could be applied to this - but don't hold your breath...

2D rotation works for components, but 3D rotation has yet to be implemented.

@unknownuser said:

can you post again in this thread when the update goes up? that's probably the easiest way for me to keep track.
thanks so much

Will do.

Developers:

While developing my CameraControls plugin, I discovered some irritating differences between browsers and JavaScript reporting of events (such as onmousemove, onmousedown, etc). That shouldn't be surprising, but it was unexpected.

In my particular case, the issue was with collecting a left mouse button event. The real issue (IMHO) is that the W3C spec is to blame. Here's why:

Per W3C specs, event.button returns a value of 0-2 based on the button pushed.
LMB returns 0
MMB returns 1
RMB returns 2
These are not bit-coded, so there's no way to handle concurrent clicks (if you wanted to do that for some reason).

In IE, event.button returns a value of 0,1,2, or 4, or combination thereof:
No mouse button returns 0
LMB returns 1
RMB returns 2
MMB returns 4
These ARE bit-coded, so a concurrent LMB+RMB (for example) would return 3.

The W3C spec is crazy (to me), because the default value is the same as the LMB value, making it impossible with event.button to determine a left click. However, most non-IE browsers also return event.which:
LMB returns 1
MMB returns 2
RMB returns 3

That's fine, except I ran into problems trying to call document.onmousedown=function in Safari(!). The defined method would fire once at load, and would refuse to fire subsequently no matter how many times I pressed my mouse button. Irritating.

The workaround for that issue was to add onmousedown events to specific objects in the document (in my case, the slider buttons). That required additional code to handle other issues that in the PC version were handled more simply with event.button.

Anyway, just some things to be aware of when trying to use DHTML+JS in WebDialogs...

Short reply: I've made progress. I think I have it working now. Will post updated version to Smustard soon.

Long, geeky reply for other developers: I found out the problem is that Safari complies with the W3C spec for mouse events, and the spec itself is to blame. For some unknown, ridiculous reason, the W3C spec states a left mouse button should return 0, a middle mouse button 1, and a right mouse button 2.

In a brilliant move, MS decided that was dumb (how can you register a left click when it returns a zero? how can you register concurrent button clicks?), rebelled, and bit-coded mouse button events in IE as left=1, right=2, middle=4. Thus, 0=no mouse button events, 3=left & right mouse buttons down, 5=left & middle buttons down, and 7=all buttons down.

Unfortunately, I didn't realize that Safari and IE were returning different values for left click events, and that's why it didn't work on Mac.

The problem became checking for the mousedown event (which I had to solve by creating separate onmousedown checks for each slider; previously, xy positioning was sufficient) and mouseup events (removing the cursor pointer from the slider still allowed the slider to move, but failed to register onmouseup events, since the mouse was no longer on the slider - solved by creating a window outside of which the sliding stops). It's been a mess, but it works now.

It's a known issue, so I'm sorry I didn't get the notice put up on the site soon enough for many of you that this is currently a PC-only tool. Trying to get this to work on OSX has been a headache, and I've not had the time lately to fix it.

I'll post when it's ready.