Entity#get_attribute() Entity#set_attribute() The dictionary name is "dynamic_attributes"

There is no need to explode - just don't create two groups. Change this: bbx1 = Sketchup.active_model.entities.add_group g1 = bbx1.entities.add_group face1 = g1.entities.add_face boxpts face1.reverse! face1.pushpull(bbxmax.z-bbxmin.z ) to bbx1 = Sketchup.active_model.entities.add_group face1 = bbx1.entities.add_face boxpts face1.reverse! face1.pushpull(bbxmax.z-bbxmin.z ) If you read your code carefully you will see that you call add_group twice, once in the root entities element and once in the first group you created.

On Mac OS X, even with XCode and command line developer tools installed, the SU installation of Ruby is not set up to enable compiling and installation of most C-library Gems. For example, one Gem I attempted assumed that there was an executable Ruby interpreter in the SU Ruby Framework where the Gem library lives (there is not - only the dynamic library loaded by SU). Fixing this requires loading a 32-bit Ruby compatible with SU, since the native installation is 64-bit. But even then the generated Makefile and other scripts fail due to problems with configuration. For example, Ruby was launched with an illegal command line option to one of the install scripts. In the end I hand-edited things and got the Gem to compile and install, only to discover as TT points out that SU's Ruby intentionally omits certain standard library components that were found to crash SU. Bottom line: with enough determination you can build a compiled-C Gem, but don't be surprised if libraries it wants are missing or if it BugSplats SU! Steve

@al hart said: Is GetShortPathName in ruby or in Win32API.so? Neither. It is in "Kernel32.dll", and you use either Win32API or DL class objects to wrap calls into that native library. See: [MSDN : GetShortPathName()](http://msdn.microsoft.com/en-us/library/windows/desktop/aa364989(v) Ruby : DL library .. and since DL ( really is deprecated, and now a wrapper into Fiddle calls,): Ruby : Fiddle library

@unknownuser said: Postby tt_su » Tue Mar 18, 2014 8:08 am When you get identity transformation, did you check the depth? Maybe the position of IP is coming from an inferred point and therefore isn't coming from inside the group/component you click on? The bug reported by Freddo a few messages above seems to be related to inference points indeed. I always get the identity from ip.transformation when the position of the cursor is along an inference line. Besides that, along inference lines, the ip.depth equals 0 and the ip.degree_of_freedom equals 1 independent whether a face was picked by the InputPoint or not. Even along inference lines, the InputPoint position seems to be correct. Update: Along inference lines, the InputPoint position seems to be the position of the point on the inference line and not of the cursor position. Ronaldo

TIG, Thanks. Indeed, once it is clear that this is an equivalent to make_group, I can manage to design a 'copy-as-group'. Thanks to all Fredo

I started a new encoding bug topic incase it's unrelated... http://sketchucation.com/forums/viewtopic.php?f=180%26amp;t=57074#p518534 can you all have a look? john

Thanks to Driven and Dan. I will use new notation instead use force_encoding. I think now it should works... #UUID in RUBY 2.0 WINDOWS ` cmd="wmic csproduct get uuid" filename = File.join(ENV["TMP"],"backquote.out") exec_string = "`" + cmd + " > " + filename + "`" exec_string.gsub! '\\', '/' eval("#{exec_string}") uuid="" open(filename, "r:BOM|utf-16le:UTF-8") do |io| uuid = io.read end`

Thank you for the formatting. The splitted version works on PC, IE11, SU 2014.

my thinking is by having the full version open, you can choose to use the 'other' interpretation.. which may make it sightly more accurate? [image: mXNK_2014-03-2809.43.18pm.png]

When it comes to push pull I understand that it does depend upon the winding (clockwise or counter clockwise) of the polygon. This is consistent and repeatable. However, with an extrusion that has a closed polyline as a path it is not repeatable. I can guarantee that the points for the face are always created exactly the same way - since they come out of a txt file. I store x and y points at 1/10000 decimal inches. The z values are set as 1/2 of the height of the door panel. I also calculate the path as x and y points which is a closed polyline. The Y values are 0. face = group.entities().add_face(face_pts) path = group.entities().add_curve(path_pts) face.followme(path) If I build the door at [0,0,0] look at it and then do a ctrl_z and repeat this process, I get a results where the the extrusion is sometimes reversed and sometimes not. It appears random - although the polyline and face are always created exactly the same way. When I create my curved stair stringers using fill_from_mesh I store each polygon's points with a clockwise winding. So far this has proved 100% predictable and repeatable. In the early days I used to do a lot of work with GIS and Windows GDI and create polypolygon this way. If you wanted to create a continent with a large lake that has an island that has a body of water you would have a series of 4 diminishing polygons each completely residing within each other. The outer most polygon would be clockwise (the continent) the large lake would be counter clockwise, the island would be clockwise and the body of water in the island would be counter clockwise. I found that the sketchup works essentially the same way with meshes.

http://www.sketchup.com/intl/en/developer/docs/ourdoc/ui#set_cursor http://www.sketchup.com/intl/en/developer/docs/ourdoc/tool#onSetCursor

I am not impressed with that book, at all. Using global variables is a no-no. Choose a name for your top level module, and write all your code within your own module namespace. Then use @vars (instance variables,) or @@vars (module variables.) Often we make each of our plugins in a sub-module of our toplevel author module.

@dacastror said: @thomthom said: In SU2014, yes. What would be the best way to write this for Sketchup 8 or 2013? (google translator) In SU8 and SU2013 and older that method is bugged. No known workaround I'm afraid.

Yeah, that should work. Thank you.

Hi Guys, Thanks for the replies. I wanted to do the way I described, cause that way the user could use any tool available to him. But, as it turns out, this seems undoable. I ended up creating my own line tool that would do what I wanted.

Thanks Dan, this can give me a hint, I'm testing with the definition given there, but in my testing model (instances.skp) gives me a wrong number of instances, sometimes less or sometimes more, I do not know if I'm misapplying the definition count_instances () # you must have a selected instance def count_instances() num = 0 if @editpath.size == 1 i = @editpath.last else revpath = @editpath.reverse i = revpath.shift end if i.is_a?(Sketchup;;ComponentInstance) num = i.definition.instances.size elsif i.is_a?(Sketchup;;Group) num = i.entities.parent.instances.size end if @editpath.size > 1 revpath.each {|i| if i.is_a?(Sketchup;;ComponentInstance) num = num * i.definition.instances.size elsif i.is_a?(Sketchup;;Group) num = num * i.entities.parent.instances.size end } end return num end mod = Sketchup.active_model sel = mod.selection ruta = mod.active_path (ruta) ? (ruta[ruta.size] = sel[0]) ; (ruta = []; ruta[0] = sel[0]) @editpath = ruta count_instances()

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.