Just a quick shot of some samples

It's done for v4. I worked hard on it last week, and now have full 3D frames [ED: and glass], mullions for non-quadrilateral faces, faster performance, and more secret stuff.

If I get time this week, it should be available next week.

It's in there I edited the above short-list to reflect that (pardon the pun). Hopefully, this will be justification for letting other projects slide a bit...

You could capture keystrokes in a modal webDialog - this will override any SU keyboard shortcuts - but beware irritating users who are used to using a shortcut for "select" that effectively cancels any active tool. Either query the shortcut list for the "select" shortcut and use it to cancel your modal webDialog, or create a really obvious "cancel" button or key.

Be careful, though, as you cannot add existing entities to a nested group. The group will exist in model.entities, and not as a nested group.

model = Sketchup.active_model
entities = model.entities
group1 = entities.add_group
face = group1.entities.add_face(points) #points should be defined, of course

#============================================================================
#  the following group, while coded to be a nested group, will not be nested
#============================================================================

group2 = group1.entities.add_group(face)

Google is aware of the situation, but I doubt we'll see a fix before v8.

Okay, hopefully I can get the observer written and working next week.

I suppose the lines2cylinders script or pipealongpath script could get you halfway there - then use makefaces to close the top and bottom surfaces.

Since a combination of scripts will do the job, then it seems likely that a single new script could do the job. Can't promise anything...

Here's the situation:

When you bring an image into SketchUp for use as a texture, a Material object is created. That object stores the original path to that texture file, so a location already exists. The free version will look in that stored location for reloading materials, and will reload it if it exists.

The pro version will let the user specify a folder to search for matching file names. I had not thought about this too much before, but I suppose each texture could be given a specific replacement. That would not be as fast for the user if they chose to do that, but it would be more flexible. The fastest/easiest way for the user would be to specify a folder for replacements.

Any need for exporting the images in a model to a folder? I know something exists that does that, but it could be added in...

nope. I've asked Google for this possibility. We'll see...

@fletch: Yeah, unfortunately, that happens a lot more than I would like. More ideas than time to implement...

The Pragmatic Programmer's Guide has some good information on modules.

Hope that helps,

There are a lot of us writing scripts/plugins, and as our numbers grow, so do the odds that someone will write something that breaks something that someone else wrote.

So, some important items to remember:

1. Try to know what others are doing/have done - this isn't always easy, but some research and questions go a long way in avoiding conflicting class/method names. It can also prevent you from duplicating someone else's effort - why re-create method x when it's already been written? Just tap into it and go (with permission, of course). Sometimes, the already-written code won't do exactly what you want. In that case, you can either subclass yours and modify the methods (for classes, obviously), or write your own using a different class/method name.

2. Try to use unique names rather than common ones - for example, if you write a "ProgressBar" class, you will cause conflicts with any other "ProgressBar" class. That will make for unhappy users, as they try to get tech support for something the author says works just fine on his machine, but clearly won't work on their machine; and will make for unhappy fellow developers, who have to hunt down the conflicting script, locate the author, and try to work out a solution.

3. Encapsulate methods in a Module or a Class - within a class, you don't have to worry about method naming conflicts, and within a module, you can be less careful about both class and method names.

4. Test your work against as many other works as possible, and test them against yours - unfortunately, the burden of compatibility will more than likely fall to the second developer. However, if you send your script to other developers asking them to test for compatibility with their works, they'll most likely be happy to oblige (subject to their own time constraints, naturally). This will help keep the user experience (and your reputation) positive.

Just some helpful tips to hopefully keep this great collective creative work going smoothly...

I've never had that happen. What code are you using to set "select"? Why are you using select[0] in the first case, and select in the second case? I did a similar test with a 4-edged face, and face.material= always set the front face, and face.back_material= always set the back face.

Explanation about the different classes:

An edge is a drawingelement, but it is not a face. It can receive a material, but it cannot receive a back material, having no back. This is the same for curves, text, instances, and groups - they can receive a material, but not a back material.

A face is a drawingelement as well, and thus inherits the .material= method. However, it does have a back, and can receive a back material. Thus, it has a unique method for that purpose.

Rather than creating a .material= method for each subclass to drawingelement, it made more sense to create it for drawingelement and let each subclass inherit that method, then add the requisite .back_material= method only for the face subclass.

Hope that helps,

So, one thing I think I'm hearing is the ability to use relative path info for external components and images - is that right? Sounds like a good idea to me.

Okay, so what is the consensus - wait for the observer to be written/tested, or release now and update later?

We can consider this my "ToDo List":

Short term:
I need to update PathCopy to rotate objects when copying to nodes.
Reload Textures free/pro versions released.

Long term:
SceneGroups is on hold until I can find a way to group multiple scenes at once.
Merge all Scene tools into one application.
Interactive modeling application

Unknown term:
Windowizer 4

Based on a request, I'm wrapping up a plugin that reloads the textures in the current model. The free version will reload all textures from their original locations. The pro version will allow selecting a source folder containing the textures to reload as well as specifying textures to reload.

This is useful if you have "placeholder" textures that you need to replace with final textures, or if you edit a texture image after it has been applied to a material in the model (for example, tweaking the texture for seamless display, or making color adjustments).

Testing the update now...

[EDIT] The remaining problem to be solved is that an exploded group/component will create "unreported" geometry if a new edge is created due to an edge from the g/c intersecting with an edge that was outside the g/c (think of a "T" where the top edge was in the g/c and the leg was outside the g/c). This geometry is not yet handled by the script, since SU isn't reporting it along with the exploded geometry. I think I need to write an observer to check all geometry created during an explode.

Tell you what - I'll modify it for you Just give me a little while...

Next week, hopefully. OT at work continues...