In my case, LibFredo6 is registered as a true extension. If you disable it from the Extension Dialog box, then all my scripts relying on LibFredo6 will be disabled. I do agree that SU should provide some built-in support for scripts relying on a common library as this becomes more frequent: managed the requirement of the Lib possibly check its version for compatibility Fredo PS: I wonder why there is a field requirement when you upload a plugin, but it is not displayed in the PS tool browser window.

Updated (2014-03-16) to copy properties of old instance to the new one.

@dacastror said: ... Dan, but I think you need to add the following properties; material, attribute_dictionaries, layer, description, entity_name, name, receives_shadows, casts_shadows I wonder if there are more properties that can be inherited by the new instance (google translator) Yes you are correct. Just before the old instance is deleted, it's properties need to be copied over to the new instance.

hi dan, this is a special IGS format what needed by the game

Thankyou - this will be a good read! I currently test on SU 7, SU 8, SU 2013 and SU 2014. The work around is easy enough.

Either that or we get the old blog up and running and link more extensive info from the docs to these longer pieces of info. Or some wiki thing. We still working on getting a better system up. Got a long list of topics to clarify.

As I recall from the last build cycle (2013,) the Sketchup::Page and Sketchup::Pages classes had issues filed on them regarding updates not working correctly. (As well as a bunch of feature addtions, by myself.)

2014 Sticky palettes are back !!! Now how about bringing back thumbnail icon of SkUp files in Finder. Was there up to v8. So practical. Anyway very happy with v2014. Full congrats to the SU team !

Thanks, that might come in handy!

I checked your extensions to invoker c#from ruby at https://github.com/icehuli/suWpfExt. I used to use win32ole to invoke my c# extensions. But since SU2014 and ruby 2.0I could not get anything up and running yet, either icehuli extension or my win32ole calls...

Al.. I PM'd you an idea.

@tig said: Never include a space between the method and the opening parenthesis that is enclosing its argument[s]... I was going to tattoo that statement on my arm, but my Wife wont let me. Regardless, I have often wondered what goes through the mind of those that write computer languages. What fantasy world do they live in? It would not be very easy to read a sentence without spaces between words, would it?

By default a texture's 'grain' always follows that axis, so your make-the-parts-rotated_and_then-rotate-them-into-place method is a winner. I think in your case it's the best approach... However, FYI you could also change the orientation of a texture for certain faces 'in code' - just like you might when using the manual 'Texture' tool - from the context-menu when a textured face is selected. I [and others] have written several UV / Texture tools - which move, scale and rotate textures - look at their code for ways to transform some UVs and then apply them to a face.material.texture... http://sketchucation.com/pluginstore?pln=TextureRandomizer http://sketchucation.com/pluginstore?pln=TIG-TextureTools

Who cares? The second one is not the format given in the API dictionary. Use the first one.

@jim said: Correct, Ruby does not process the lines between. They are typically used for block comments. And if used, the equal sign must be the first character in the line (no whitespace.) Thank you for the answer. that helps me understand a bit more of ruby scripting

Thanks.

There is no issue with SketchUcation's AutoInstallers ! IF there are additional folder-paths found in the $LOAD_PATH - either because Fredo's AdditionalPlugisnFolder tool has added them OR because the 'shared' C:/ProgramData../Plugins exists - then these locations are offered as alternative destinations for an SCF AutoInstall [with the User's Plugins folder as the first one listed] - unlike the native Preferences > Extensions > Install which is always into the User's Plugins folder. To reiterate... The C:/ProgramData../Plugins folder is for use when a computer is to use a 'shared' Plugin or Plugins. Such Plugins are then auto-loaded as SketchUp starts for every user on that computer. The default installation location is into the User's Plugins folder - this means that each Plugin a user installs into that folder is only auto-loaded as SketchUp starts for that user. Many users will not want or need a second 'shared' Plugins folder. Even if there is more than one SketchUp user on that computer they may well prefer to keep their own 'User' Plugins separately. Having a shared Plugins folder when it is not wanted/needed imposes unnecessary complexity on a user. If your installer bulldozes across a user's current setup and creates a new 'shared' Plugins folder, then it stands to reason that they might not be happy about it. Automatically creating it and changing things without asking is not a responsible approach [IMHO]. If that shared Plugins folder already exists then there is possibly not change to their arrangements... but even if the shared Plugins folder does already exist, then your automatic installation of things into it is contrary to the normal installation of Plugins, which always auto-install with Preferences > Extensions > Install into the User's Plugins folder, or with the SCF AutoInstallers you are given the choice of folder, defaulting to the User's Plugins folder. After all, the user might not want to share your plugin will all of the other users on that computer: even if the shared Plugins folder is preexisting it is no indicator of the user's desires. So I think your installer should offer two installation destinations: User's Plugins folder Shared Plugins folder If the shared folder doesn't exist, then in fairness you ought to warn that creating a shared folder might affect some aspects of future installations... This approach seems common-sense to me Why do you want to go against the tide

TIG, I didn't need the parallel code. I wanted to return the original pts and the flattened one pt1 = @ip1.position pt2 = @ip2.position p1 = Geom;;Point3d.new(pt1.x, pt1.y, [pt1.z, pt2.z].min) p2 = Geom;;Point3d.new(pt2.x, pt2.y, [pt1.z, pt2.z].min) eye = Sketchup.active_model.active_view.camera.eye ve1 = eye.vector_to(p1) ve2 = eye.vector_to(p2) return [pt2,pt1,p2] if( ve1.cross(ve2).z > 0 ) [pt1,pt2,p1] [image: KvVy_doorsaroundcircle.JPG]

There is tiny open source project, that does exactly what you are looking for: http://sourceforge.net/projects/makeavi

We stay away from using global variables in a shared objectspace like SketchUp Ruby. I will assumed the Box is made of grouped primitives: grp = Sketchup.active_model.entities.grep(Sketchup;;Group).find {|g| g.name="Box" } if grp @pos = grp.transformation.origin end