Your error message pointed to the last line in your code: classify (u, apoint, face1) I suspect it was the space between the method name and parentheses. Especially when you encounter syntax error it's good to go over your code and make sure the code style is consistent. Checking that there are no spaces between parentheses in method calls and making sure you have parentheses around all arguments etc.

Sounds like you need to implement a custom Tool: http://www.sketchup.com/intl/en/developer/docs/ourdoc/tool You can make the tool select entities the user clicks on by using the PickHelper class. Both these classes has examples in the documentation that will get you started.

From a time complexity perspective I think the problem is inherently O(n^2) (which means that your code can't be any simpler), also, if the curves have few segments and you already know enough to throw away half of them, then I would say your code is probably close to optimal. In general, the simplest way to gain speed is to use bounding boxes in various ways like reducing the input to segments in the bounding box intersection between the curves and so on, however, there are constant costs associated with this so it may not be a gain on small inputs.

Ah, yea - there is name and display_name - at least in the Ruby API. name is the unique one that should be used to refer to materials. display_name should be used only to display the material name to the UI. However, it appear that the C API doesn't quite do that. Let me have a chat with the rest of the team.

I can reproduce what you see when I use a larger texture. I also notice that the Console output is odd. lots of empty lines and a strange order of the lines. I'm not sure what it is yet.

did you have a look at http://sketchucation.com/pluginstore?pln=InfinitePanOrbit I did a mac hack to help out with it, is that the kind of thing your after? john

@lersince1991 said: Hi, I am trying to use this but all the textures are out of scale completely (254mm x 254mm) and lose their aspect ratio. Is there any way (I dont know ruby script) that someone could modify this rb script and give it a prompt for material scale and for it to maintain the aspect ratio? Old discussion: http://sketchucation.com/forums/viewtopic.php?f=180%26amp;t=17857 Original rb download link: http://rhin.crai.archi.fr/rld/plugin_details.php?id=241 Much appreciated! You can specify a size, width and height, but not a scale. If you are interested I can PM you a copy which allows size input for each texture.

hi guys, situation is the same with sketchup 2014? i want to make a toolbar with organises approx. 50 tools (each tool is simply the link to a dynamic component). A drop-down menu in the toolbar would be I think best solution. Just like the one what appear in "Getting Started" toolbar. I dont want to make the equivalent in webdialogs, it is possible but i think it would be a mess. please, any ideas?

@sr20vet said: Yep, I've taken the native threads path. Got the thread running, got even an http server running in that thread. But now, GIL is killing me. Can't call ruby from that second native thread... May I ask what exactly you are trying to do? I think you can call ruby from that second native thread. One important point is that the ruby function needs to be involved in the ruby thread, i.e. the SU thread. So in the c-extension there should be two threads, one is the same SU thread, the other is your second native thread. All ruby codes need to run within the SU thread.

To recap. Component definitions can have attributes. These apply to the definition and are therefore accessible via definition.get_attribute(...) Component definitions can have entities, These entities can have attributes. These apply to the entities with the definition, and are therefore accessible via some_entity.get_attribute(...) Component instances can have attributes. These apply to the instance and are therefore accessible via instance.get_attribute(...) If you have an attribute set for any entity that is within a definition.entities context, then that attribute is accessible all instance.definition.entities - i.e. it is the same attribute, and therefore if you ' .set_...' it, it affects every instance sharing that definition - just as if you had painted a face 'red' inside the definition you should expect every instance to show that subsequently.

nope, I have not copied, create the object there. There are also problems when making copies when it is inside a group or component nonorthogonal... is very strange behavior you describe (google translator)

I have looked further and I can confirm that zero length strings as keys will cause this. Nil values will convert to empty strings. So as a workaround until we fix this bug please validate the key provided to set_attribute.

Still trying to figure it out. Tested it by putting the code directly into the Ruby Console and putting it into a rb-file. Try with a freshly started Sketchup 2014 and delete 'Sophie' (but leave her in the component definitions). First I executed in the Ruby Console: @model = Sketchup.active_model @ents = @model.entities @defs = @model.definitions inst = @defs["Sophie"] @model.place_component inst,false Place her anywhere but not on the origin 0,0,0 Second run this: @ents.each {|e| next unless e.is_a?(Sketchup;;ComponentInstance) puts e.transformation.origin } You get the proper coordinates of Sophie. Now I delete all Sophies but leave her in the component definitions. I wrap the above code into a plugin. I need to add an observer so the code can pick it up again (place_component breaks the code). I load it and start it with: MB_place_instance.activate The first placed instance always returns 0,0,0 as the origin. Add another one (activate again) and it returns the origin of the first added instance etc... Looks like its returning the definition and not the placed instance. There must be some logic in it but I fail to see it... require 'sketchup.rb' module MB_place_instance class MyDefObserver < Sketchup;;DefinitionObserver ### create an observer (place_component breaks the code and returns to SU) ### def onComponentInstanceAdded(definition, instance) puts "observer has fired; " + instance.to_s MB_place_instance.refire(instance) # go back to the tool end end def self.activate @model = Sketchup.active_model @ents = @model.entities @defs = @model.definitions inst = @defs["Sophie"] @observer = MyDefObserver.new @model.definitions[0].add_observer(@observer) @model.place_component inst,false end #def def self.refire(instance) @defs[0].remove_observer(@observer) # delete the observer @observer = nil # delete the observer in case previous method fails GC.start # collect garbage @ents.each {|e| next unless e.is_a?(Sketchup;;ComponentInstance) puts "looking with each; #{e.transformation.origin}" } puts "directly adressing passed instance; #{instance.transformation.origin}" end #def end #module ### start in RubyConsole with; MB_place_instance.activate

Thanks TIG. I like this solution. It should work in principle for the objects whose properties I am going to change. I think I have to change the way I store the objects though. Let me explain. The goal is to produce an insolation contour across the development (at ground level). To do this I do the following: 1 - mesh the surface that represents the interstitial space between buildings 2 - for each grid node I cast rays to cover the whole hemisphere 3 - for each ray I use raytest to verify whether I see the sky or I see an obstruction (this obstruction can be transparent or it can have an assigned temperature) Each Ray is an object with properties: direction, shaded_state, temperature, transparency and so on (there is no reference to Sketchup objects) Each grid node is represented by grid_node object with properties: coordinates and an array of Rays In order to implement your solution I think I will need to store the reference to the actual object that the Ray sees (if it does). I am not sure I can store a reference to a SketchUp object? Would the search in the datafile be faster than the re-calculation? I will test. Your proposed solution will not help though for the impact that a NEW object can have on specific grid nodes. My idea for this case was to replace the raytest with an intersection test between the new object (this is usually some form of local shading such trees, canopies, etc.) and the various rays for each grid node. I guess that the intersection test should be faster than raytest. Thanks again.

Problem solved!!! It's all about vectors. One of the arguments of the method that is resposable for creating the protrusions must be a vector or the order of the four given points of the rectangle must choosen in a way that the vector can be derived as the difference between the first two points of de rectangle. ` def findface(pt) arr = Sketchup.active_model.entities.grep(Sketchup::Face) arr.each {|f| return f if f.classify_point(pt) == Sketchup::Face::PointInside} return nil end def body ents = Sketchup.active_model.entities ents.clear! f = ents.add_face([0, 0, 0], [60, 0, 0], [60, 40, 0], [0, 40, 0]) f.pushpull(-30) end def protr(array, extrusion) ents = Sketchup.active_model.entities base = ents.add_face(array) arcvector = array[1].vector_to(array[0]) basenormal = base.normal depthvector = basenormal.cross(arcvector).reverse width = array[1].distance(array[0]) depth = array[2].distance(array[1]) basenormal.length = extrusion - width/2 basecenter = Geom::Point3d.new basecenter.x = (array[0].x + array[1].x)/2 basecenter.y = (array[0].y + array[1].y)/2 basecenter.z = (array[0].z + array[1].z)/2 center = basecenter + basenormal base.pushpull(extrusion + 1) ents.add_arc(center, arcvector, depthvector, width/2, 0, Math::PI) basenormal.length = extrusion + 0.5 findface(basecenter + basenormal).pushpull(-depth) ents.add_circle(center, depthvector, 1) findface(center).pushpull(-depth) end def test body protr [[22.0, 8.0, 30.0], [22.0, 20.0, 30.0], [10.0, 20.0, 30.0], [10.0, 8.0, 30.0]], 14.0 protr [[35.0, 8.0, 30.0], [47.0, 8.0, 30.0], [47.0, 20.0, 30.0], [35.0, 20.0, 30.0]], 14.0 end`

Oh wait, Fiddle::Importer is very similar to DL::Importable. I will migrate to Fiddle. Sorry for misleading you guys. Thanks for all the help

Thanks very much, cleaning up html did the job. If its still of intereset, i use windows 7. Haven't seen my HTML mistake, so thanks again, curator

@tt_su said: @sdmitch said: Early on I had problems using .get_element_value so I never thought about it again opting to get the values from the "p" string. What problem was that? I also utilize get_element_value for callbacks from JS to Ruby. I use a bridge that convert basic Ruby and JS objects back and forth with synchronous callback on both platform. Using an input element as data transfer is my standard technique. It was very early in my plugin career and involved radio buttons. As soon as I found something else that worked, I never tried using it again. I'm sure it was mostly, if not all, operator error.

@tt_su said: This .hash change affects only String, yes? The above Ruby bugs thread mentions Object#hash being overhauled (which is inherited by every object, unless overriden.) So a test under SketchUp 2014 & Ruby 2.0: (1) Open a SketchUp session, and in the console: Sketchup.hash %(#004000)[>> -112701995] This is the method that the Module class inherits from Object. (2) Close this SketchUp session, reopen SketchUp, and in the console: Sketchup.hash %(#004000)[>> -226388390]

@dan rathbun said: My point remains valid. You CAN see the code. You can see what exceptions the API methods raise internally themselves and their messages for ArgumentError and TypeError exceptions. It is in fact not easy to see where all the errors are raised from. I was struggling with that the other day while I was working on an issue. There are a lot of utility methods that might raise errors and it's not easy to see all the code paths. I didn't intent to make an excuse to not so anything, but the majority of the API was made many years ago - long before anyone on my team was around. Tracing down all of them would be a lot of work. Would have been easier had it been done since the design, but alas. Just wanted to give some insight to why things are such as they are. It doesn't mean we don't agree with you. That the documentation is not the best is well known, and you know I've ranted for years about it. One thing we really do want is a new documentation site - a new developer site.