@dan rathbun said: Secondly... your breaking a cardinal rule of global variables. DO NOT create them only for use by one single plugin, or for only YOUR own use. Create either Constants, or Module or Class variables, within YOUR namespaces. (That way they will not conflict with other sloppy scripts that are using globals of the same name.) My bad! I only use global variables to confirm values in the Ruby console, If the console could evaluate @ variables I would never, never ever use $ variables.

Ahh, interesting. Odd to me that a and w both make new files, but r does not. Oh well. Very good, now to fill my files with useful data. Thanks guys, Chris

If you erase a long edge and draw another one there is no new face, if you erase a short edge and draw another one there is a new face. This s is a common issue with manually drawn faces where tiny tolerances cause issues, BUT the edges are coplanar enough to keep a face!

I've got a personal plugin that does this. I shoot rays to test if the line crosses an edge. It works well enough. Though I am not triangulating from each vertex, but from the cursor. I could email you a copy if you want to see it in action. Chris

Ok..................

@tig said: Moving one vertex and then perhaps another will often have a quite different results, compared to moving them all in one fell swoop with the entities. transformation methods that do all of the changes together... Plus - it's much much faster to perform one big entity transformation instead of many.

Do not ignore Dan Berger's windows-pr package. It goes along with his win32-api package. Has the Windows "unicode.rb" In windows-apt-0.4.0 there's a complementary file "wide_string.rb"

The docs should really be mentioning this.

Grrr,I hate the "smart" pages. There are no comments on my API pages.I will try to change setting in my browser. @unknownuser said: But using the 'group.transformation' for both required transformations to ensure that the group's geometry intersects with itself, and it returns the intersection geometry in the same location should work ? Perhaps not if the group has been moved ?? I have tested it... and it is only ok, if both the transformations are "new".

For your "point and plane test" it's easy enough to make your own tool's method without messing on with any base-classes... def point_test(point, plane, cond=false) ### 'point' is the point to test, ### 'plane' is the plane to test and ### 'cond' allows you to return true/false IF point is ON the plane. ### NOW add your code here that see if the 'point' is on, in front or behind the 'plane' ### returns 'behind' as 'true' or 'false', with a tweak for the 'cond' setting if behind return false else return true end#if end#def Then in other code within your toolset use self.point_test(point, plane, true) where 'point' is to be tested for its relationship with 'plane', and here the third argument 'true' says to take 'point' as being 'in front' even if it's ON the plane too... [you would use no third argument or 'false' if point ON plane is to be 'invalid']

That's about it! If the plane is from a face the face.normal is easily found. You could also extract the plane's vector from it's 'array' ? Project the original_point onto the plane, then offset! that cloned_point along the plane's 'normal' vector by the distance between the original_point and its projected cloned_point... and then if cloned_point == original_point the original_point is in front of the plane, otherwise it's behind the plane; you should also check separately for the original_point being exactly on the plane... and decide whether that counts or not.

Sure, anyone can use the lib if they want. I've tried to document as much as possible.

@lothcat said: Thank you so much! It's working now and I'm not having that weird loading bug! Excellent! @lothcat said: Also, thank you for being patient with me. This was a real learning experience. I would be very worried if you had not learned anything, here ....

As I suspected then... Using ents.add_group(ent_array) only works safely if ents==model.active_entities So use my cloning tips...

If 'lenx' is '=value' can't you change the contents of the 'value' attribute itself [or if that is itself set in some complex way then change the attribute[s] that it is using etc...], which on a redraw then changes the contents of the DC.

Programming a Tool class is another topic. It's best to read the examples supplied by Google, in the "Plugins/Examples/linetool.rb" the instance var @state is used to store what 'step' the tool is at.

You might have a look at this plugin - it seems similar to what you are describing.

@thomthom said: Do you have any sample code to demonstrate? I will try to get sample code up here - just busy at the moment... Thanks guys.

Rotation and Scaling are inexorably linked in a transformation - hence the weirdness... Can I suggest another approach... You are trying to align two objects they both have obj.transformation.axes and you can transform in steps... Therefore you can move the objects together using [ tm=Geom::Transformation.translation(vector_from_point_to_point)] and then rotate one to align with [ tr=Geom::Transformation.rotation(point, axis, angle)] you can 'combine' transformations thus t=tm*tr and then use obj.transform!(t) in one step... but note that the 'order' is important in a matrix * and the order of the transformations it will do is always taken as right-to-left... i.e. the move then the rotation - unlike normal numerical multiplication it's not commutative for matrices! Moving and then rotating will not necessarily give the same result as rotating and then moving - depending on the relativity of points etc... PS: Put your code inside a [ code ]...[ /code ] block as it's easier to read. You are using a $ variable - dangerous as it's exposed to all other tools and such a common name may well clash with other authors' unwrapped code too... Use @ or @@ variables that span methods within your own module/class only... Parenthesize your arguments as method(1, 2, 3) rather than method 1, 2, 3 - although both work upcoming versions of Ruby may well deprecate unparenthesized arguments and even the most recent update caused some problems - I know th API guidance and many example scripts do it the 'wrong way' but it's a good habit to get now, before your code gets out of date unnecessarily...