# LDraw.org Discussion Forums

You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
(2020-05-05, 20:54)Roland Melkert Wrote: [ -> ]It's a fairly simple one if you assume it's on the abs yz plane

Code:
```function onRun()   local sel=ldc.selection()   if sel:getRefCount()<3 then     return   end   local a=sel:getRef(1):getPos()   local b=sel:getRef(2):getPos()   local c=sel:getRef(3):getPos()   a:setX(0)   b:setX(0)   c:setX(0)   c:setY(b:getY())   local ab=a:getLength(b)   local bc=b:getLength(c)   local bb1=ldc.vector(1,0,0):getSignedAngle(a-b, c-b)   local bb2=math.deg(math.acos(bc/ab))   local angle=-(bb1-bb2)   ldc.setClipboardText(angle)   ldc.dialog.runMessage(angle) end function register()   local macro=ldc.macro('My macro')   macro:setEvent('run', 'onRun') end register()```

Could use some more cleanups and dummy proof checks though

It gave me the idea to add access to the relative grid in 1.7, so thanks for that

See, now that I see it written out, it makes perfect sense. :-)

This did indeed work, once I a) rotated the model into the YZ plane, and b) replaced the group I was rotating with a submodel (because the script is looking for refs).
(2020-05-05, 22:07)Roland Melkert Wrote: [ -> ]I realized if you assume all selection points are on a plane, you can drop the setX/setY lines and calculate the plane normal instead of using a static x vector

Code:
```function onRun()   local sel=ldc.selection()   if sel:getRefCount()<3 then     return   end   local a=sel:getRef(1):getPos()   local b=sel:getRef(2):getPos()   local c=sel:getRef(3):getPos()   local ba=a-b   local bc=c-b   local n=bc:getCross(ba)   n:normalize()   local bb1=n:getSignedAngle(ba, bc)   local bb2=math.deg(math.acos(bc:getLength()/ba:getLength()))   local angle=-(bb1-bb2)   ldc.setClipboardText(angle)   ldc.dialog.runMessage(angle) end```

neg y makes it somewhat confusing but i think this should work in any orientation, not tested though.

This version got me close, but not quite:
[attachment=5188]
(2020-05-06, 3:14)N. W. Perry Wrote: [ -> ]This version got me close, but not quite:

It works for me, gives angle -53.13 same as with the first version of the script.

Did you use helper parts whom all use the same x coordinate, placing the whole thing on the yz plane.
(2020-05-06, 5:32)Roland Melkert Wrote: [ -> ]It works for me, gives angle -53.13 same as with the first version of the script.

Did you use helper parts whom all use the same x coordinate, placing the whole thing on the yz plane.

Yes…didn't think of that, to be honest, but they happen to be correct. Don't remember for sure since I didn't save the test file, but trying it now works correctly.

Looks like it was the same group vs. submodel problem. I can recreate the problem by selecting just the first helper part, and the group; it calculates the angle using the two parts in the group as getRef(2) and getRef(3), ignoring the second helper part.

Easiest fix, obviously, is to use a helper part at the rotation center, since the hinge part unhelpfully has its origin elsewhere…
(2020-05-06, 16:42)N. W. Perry Wrote: [ -> ]Looks like it was the same group vs. submodel problem. I can recreate the problem by selecting just the first helper part, and the group; it calculates the angle using the two parts in the group as getRef(2) and getRef(3), ignoring the second helper part.

Ah I forgot about groups in my little test scenario, you can fix that by using getLineCount() / getLine() instead of the ref variants.
(2020-05-06, 19:18)Roland Melkert Wrote: [ -> ]Ah I forgot about groups in my little test scenario, you can fix that by using getLineCount() / getLine() instead of the ref variants.

Should it be a straight find-&-replace for that text? Doing this, it complained that getPos was a nil value.
(2020-05-06, 21:01)N. W. Perry Wrote: [ -> ]Should it be a straight find-&-replace for that text? Doing this, it complained that getPos was a nil value.

Sometimes I forget the rules of my own scripting api

getRef does work with groups but it might have a different center, so in the end it shouldn't matter as long the group's center is also on the same x (or whatever plane coordinate) as the other items in the selection.

Otherwise it shouldn't even run the calculation as the first line stops the execution if there are less then 3 items in the selection.  This would be true if one of them were a group while those where excluded.
(2020-05-06, 21:31)Roland Melkert Wrote: [ -> ]Sometimes I forget the rules of my own scripting api

getRef does work with groups but it might have a different center, so in the end it shouldn't matter as long the group's center is also on the same x (or whatever plane coordinate) as the other items in the selection.

Otherwise it shouldn't even run the calculation as the first line stops the execution if there are less then 3 items in the selection.  This would be true if one of them were a group while those where excluded.

Well, that's just it—it does seem to do the calculation, if I select only the first helper part, and the group. (The group contains two parts/refs: the hinge top, and the 2x4 plate.) This is when I get the not-quite-correct angle of 48.-something, I assume because it's using the origin of the hinge top as the B point, being the first part in the group. But the group center is set to where the hinge rotates, and it's properly planar and everything.

But when I change the group to a submodel, with the same rotation point set as its origin, everything works properly.
(2020-05-07, 2:45)N. W. Perry Wrote: [ -> ]I assume because it's using the origin of the hinge top as the B point, being the first part in the group. But the group center is set to where the hinge rotates, and it's properly planar and everything.
This sounds like a bug , getPos should return the group center not the main line center.

I'll look into it.
(2020-05-05, 19:27)Orion Pobursky Wrote: [ -> ]You could, probably, do this now with a script. If I didn’t already have like 5 project plates spinning, I’d finally learn how to script in LDCad and eliminate the need for my spreadsheets.
This is, exactly, why I asked for the top "feature" making a better documentation of both the script language and the object model in LDCAD. Roland, can you think about this, please? At least put all scripts from this forum, as you post them time to time, to one place at your WWW site, with comments. Better if you document even more.

Esp. if you want to work on LDCAD 2.0 and expect we add more features to LDCAD 1.7 ourselves, using scripts. The documentation would be really helpful. The better the more helpful
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15