Was gonna post a snippet this morning but you guys did the work for me So I see John, you got an error "is a Pro only feature." That pretty much sums it up. Like Tig also suspected. Dan said. @unknownuser said: Makes sense.. otherwise we'd be able to write Pro feature custom tools for Free Yeah, thats why I posted the question. Being a PRO user I momentarily took this method for granted when I did not receive an error message in my code. Thanks everyone involved for clearing this up. Maybe Google should put PRO label for methods like this after the 8+ in the API.

Ah, thanks. Doing some tiling with thoose mesurements. Should be ok then.. @unknownuser said: The internal unit is converted to user units only in the UI That's why I got back different results in the ruby console when changing the Model precision. Maybe that goes for some other mesurement as well, havent just thought about it until now. @unknownuser said: When dealing with user units, make the Length class do the work for it. And make sure you know if your objects are Floats or Lengths. I'll try to stick to that.

OOPs There was a typo in my code. Now the comps are loading(hopefully). Forget the last post. Edit: Problem solved by saving components(like Dan said) in user/my documents/anyfolder. Then I can copy and paste from there.

Asking is probably wise. I'll see what I'll do later on. It's also not that hard creating new icons Thanks for the advice, both of you!

Yeah, thanks TIG. All what you say is true. All these transformations got my head spinning. So I ditched the scaling in the tilingmethod. Went with scaling(y in this case) at ORIGIN, just after loading the component. Before placing it on the face. Not as flexible as in a method, but it will hopefully work. I think Dan suggested something similar, earlier on in this thread. Maybe that's what you had in mind all along as well, TIG. I just coulden't see it then.. Edit: When I reread you thread, did you mean to scale entities and that would become a "local" scale? Cause i did some scaling in x or y and it was in fact a global scale. The group moved from the face and tilted, even when putting the origin at center of bbox. I can't recall 100% sure if it was the group OR the entities I scaled. Ah heck. I'll try tomorrow then.. Like I said, rather had this transformation separate in the tiling method..

Great info. I probably should get that windowiser4 plugin then. It does seam very handy as a plugin, as well Thanks

Thank you TIG. Really appreciate it! I havent done any update for a long time and must get up to date with how the pluginstore works, more in detail. I suppose I should move the manual there to, perhaps ? Did not manage to downsize it to less then 1.8 mb.

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

@jolran said: However there is no "glue_to" method for groups in the API. Right.. and you should not use a Group, for the job of a ComponentInstance. Groups are best used for temporary editing both manual and in scripting. By collecting objects together into a Group, you can: move them from one edit context to another, protect them from being modified by crossing edges, apply a tranform to a set of objects all at once (where they move, scale or rotate all together.) I would say, that when you get a "set" of objects the way you want, and then wish to use that set multiple places in the model, it's best to then convert them into a ComponentInstance. Especially if your going use scripting, to manipulate them, or glue them to faces.

He he!! Thats the price to pay! Interesting you should mention. I was doing a test. Thats quite a few hatches.... [image: UPBg_Quantity.jpg]

@Rich-O-Brien Thank you very much!

Great! That makes things a lot clearer. @unknownuser said: Avoid global $ variables that can clash with other's coding as they are accessible to everything! Thats especially the thing I was not sure about about. The last thing I wanna do is barge in here ruin everyones scripts.. Thanks a lot!

I finally got TIG's version going(forgot to comment out #def.self when running it in R.code.editor, amanidiot!) SOme funky thing going on when changing hatch_angle. But its stable and works in any axis. Not what can be said about "my" script. A bit unstable, until the intersectionpart. My intuition tells me doing copying edges within groups + intersection gives more predictable hatch_result when rotating hatches. But is alot more unstable when gathering and erasing? Plan A: Stop whining and get the work done so Layout-users finally have a hatch-plugin Plan B: Adjust TIG's script so it works in all angles, with menus and such. (will be difficult, since I don't totally understand it yet) PlanC: Continue to work on mine(a bit egoistic but I won't learn from copy/paste), integration as much of TIG's script as I can, thus make my script more stable if possible. However. That might not be possible, and I would have to do at least 5 different methods for views. I guess I'm asking if there is any pointers for things to avoid that make this script crash.

AAHH! Yes! Now it works. I spotted the . 25cm mistake. But did not think about the spaces. Thank you very much TIG and Jim!! I've learned a lot from this. Now I need to learn what has really happend in the code And acctually I only needed 1 edge in the group. I did not know one could add the entities in an empty group. This is a lot better.

@unknownuser said: Of course you can use any API tools within ANY entities context. Thats even better. I learned a lot from this, thanks all! Have to analyze this info and make me understand it fully. Local and Global coordinate system can be a little daunting to dig into for a newbie, but you explained it very well.

Thanks

It works! Of course.. But not with my current project... Did a new simple scene and "save as 6" and it worked fine. Could open the file in SU version 6. Sometime my file got corrupted. Funny its only in the backwardsconversion Im having difficulties with the model. Works with Kerky for ex. I work on the model and if I come up with a new idea I save it with a different name "save as". is that a bad workflow? Should one copy and paste in new SU window? Shouldent make any difference in my logic. Anyway. It is (probably) not a bug then.