(2020-04-24, 0:16)N. W. Perry Wrote: Which, I assume, would mean storing that string in a meta tag, or maybe as shadow content?

(2020-04-24, 0:16)N. W. Perry Wrote: That's an option indeed. But since I use submodels for organizational reasons, I think for my purposes that's more important than this precision issue. I think as long as I place everything correctly before exiting the file, I'll know that the saved values are as clean and precise as they should be, which will be good enough for me. (I just have to avoid the urge to check the relative positions again after re-opening the file!) 

(2020-04-24, 2:33)Roland Melkert Wrote: No I meant like
0.637276437432e-22
but 3 digits is considered 'normal' behaviour.

you could also try increasing the
modelFileDecCnt
setting in main.cfg

(2020-04-24, 17:04)N. W. Perry Wrote: I think I'm at a good place for now

(2020-04-24, 17:04)N. W. Perry Wrote: Does the decimal count persist once it's saved in a file, or would LDCad overwrite the coded values if I opened and re-saved a file with different precision?

(2020-04-24, 19:26)Roland Melkert Wrote: Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision

Quote:The option only affects writing of files, reading will always use up to 19 decimal points.

The 19 comes from the maximum power of 10 in a 64 bit integer which is used to store the number after the dot before it's converted to double.

(2020-04-24, 23:29)N. W. Perry Wrote: Yeah…my fear is that I switch to 5 decimal places, and now I'm haunted by rounding errors that are .00001 instead of just .001! 


So, if I were to switch from say, 3 to 5 places, and I save a new file…then later I decide to go back to 3 places and re-save that file, it would round all the values down? (I suppose I could just try and see what happens.)

• The point ( A ) on a rotated part/assembly that will collide with the stationary surface
  
• The rotation center ( B )
  
• A point ( C ) orthogonal to the rotation center along the stationary surface
  

(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.

(2020-05-05, 19:44)N. W. Perry Wrote: Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning. 

(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

(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.

(2020-05-06, 3:14)N. W. Perry Wrote: This version got me close, but not quite:

(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.

(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.

(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.

(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.

(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.

(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.

(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.

(2020-05-08, 20:05)Milan Vančura Wrote: 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.

(2020-01-13, 20:41)Roland Melkert Wrote: - !DATA support

(2020-05-23, 12:53)Lasse Deleuran Wrote: I have run into issues with a user who has used LDCad to create instructions with BUFEXCH commands, see: https://github.com/LasseD/buildinginstructions.js/issues/34

As you can see, the issue appears to be a lack of "0" prefixes in the buffer-exchange-specific regions, causing LDCad to output files that are not interpreted correctly in software that does not support Buffer Exchange commands. 

Can you please share the specification which you have used for the existing support, and are you aware of other commands in LDCad which might cause other software to render stuff incorrectly?

(2020-05-23, 18:11)Roland Melkert Wrote: I'm not sure I understand the problem, do you mean you expected the "0 " prefixes on the ghost lines to be added automatically ?

If so that's not part of the bufxchg spec.

0 GHOST  is a different mlcad meta, which it uses to draw parts transparently I believe.

It is just added as a prefix to lines which the user wants 'ghosted'.


I used MLCad's documentation to implement bufxchg
http://mlcad.lm-software.com/e_default.htm

It is basically a stack command, meaning you store the whole LDraw content at the STORE point and trow away the current content upon a RETRIEVE.

I did implement it as a hide flag in LDCad as I don't want to literately delete stuff

The main trick is to loop backwards trough the LDraw lines when processing the commands, that way nested ones are automatically handled correctly.

Quote:Ghost commands are a special form of other commands. Any MLCad or Ldraw command can be a ghost command. To make a command to a ghost command simply put “0 GHOST” at the beginning of the line.
So what’s the deal with this type of command?
MLCad displays ghost commands only if the model containing the command is the main model. If the model is a sub-model of another or simply a part included into a model the ghost lines are simply ignored. They are useful in connection with the buffer exchange command and allow to show detailed assembly instructions of a part when it’s viewed by its own, but if it’s included as a part these steps will not be shown.
Without this ghost command you would see things between buffer exchange commands uncontrolled since buffer exchange commands are also ignored in sub-models.

(2020-05-23, 18:37)Lasse Deleuran Wrote: That explains the issue. The two commands go hand-in-hand to ensure compatibility with other LDraw software, such as LDView.

In the documentation you link to, the section with GHOST says (highlight mine):

And this is the issue with their models. LDCad outputs the stuff between SAVE and RETRIEVE without any modification, so other viewers will simply also render all the stuff in those sections.

(2020-05-23, 19:10)Roland Melkert Wrote: Now I see, I  actually implement nested BUFXCHG meaning it will also work on submodels.

To this end I keep track of two visibility flags one for visibility as seen from the last step (submodel state) and one for the current step of the model you're working on.

This is a fairly easy fix and prevents littering all those GHOST meta's imho.

But if you want to use the ghost tag in your instructions you can use the newly added "toggle ghosted lines" macro of 1.6d, it's in the scripts/mlcad menu.

(2020-05-23, 16:55)N. W. Perry Wrote: Is it possible to display the length of flexible parts dynamically as I edit the part? Most of the time, this means in nested mode, whereas now you have to exit nested mode and highlight the whole part. (I wouldn't mind also if it displayed the greater precision used in the generated code.)

(2020-05-23, 16:55)N. W. Perry Wrote: While I'm on the subject, I feel like there may be bugs in the length parameters of the path dialog. For example, if I set a length display offset, it vanishes next time I open the dialog. And if I set the unit to LDraw, the displayed length is some wild enormous number—but what it writes into the code is correct. Maybe this is a know issue, but if not I can go into more detail.

(2020-05-23, 22:31)Roland Melkert Wrote: If you open the MPD contents group in the bin, you can inspect the length using the flexible part's bin cell hint.

And if you open the parts own editing session you can also get extra information by opening the information icon at the right bottom.

That said, it might be handy to have it somewhere more prominent while working with the control points.

Maybe add it to the coordinate panel when anything path related is selected ?

Quote:Sounds like a bug, but I can't replicate it.

I assume you talking about these settings?

Quote:Are you using 1.6d because I did change something concerning those settings in 1.6c (added the L option) so I may have broken something during that.

(2020-05-24, 2:48)N. W. Perry Wrote: But the other part is easy to replicate:

(2020-06-19, 22:08)Miguel Reizinho Wrote: I would find very useful if, when you have a part selected, the information would still be displayed in the status bar. And that you could configure a right click menu (perhaps in text file) that would open URLs. And Double click for a default URL!

In the example above, If I would right click on the status bar, a menu would pop up that would have the following options:

Open Part in:

Bricklink (default)
Brickset
LDraw Part Tracker

(2020-06-21, 20:50)Milan Vančura Wrote: Great idea!
Better said, two ideas:

1. the first one is doable: do not clear the part description from status bar immediately after mouse cursor is out of the part. I'd add "think up how to display a complete description" because many times the description text is too long for the status bar
2. URLs, configurable - great idea! However, it'd need a transition from LDCAD part codes to BL ones, which is an ongoing project, AFAIK.

(2020-06-22, 17:02)Roland Melkert Wrote: Both hints and selection properties are better handled in my 2.0 plans.

1.7 is a '2.0 takes to long so lets do another 1.x to fast-track some fun stuff' version   So I don't want to big changes to the way things generally work. That said I could add a simple option to not clear the hint bar when the mouse is on nothing.

The second point might be possible using a macro, but I'll have to look into that some more know for sure.

(2020-06-26, 12:17)Lasse Deleuran Wrote: If the Web-viewer for OMR can auto-generate content based on the LDCad commands, then we can save a lot of disk space and a lot of network traffic, while still being able to generate fallback geometries when downloading from scripts. For this reason I would like to implement this functionality.

I seem to recall someone else was interested in the algorithms for generating the fallback geometries. Is this open sourced? If not, would it be a problem that the OMR viewer uses open source code for generating the fallback geometries?

(2020-07-06, 3:06)N. W. Perry Wrote: may I suggest a "Reselect" command (or "Select->Previous" or "Select->Again") for those times when you accidentally de-select those dozens of scattered parts you just spent several minutes clicking on. :-)

(2020-07-07, 19:48)Roland Melkert Wrote: I know some programs include selection changes in the undo information, but I always found that somewhat annoying. I might make it an option if it can be done without to much change.

(2020-08-19, 15:35)N. W. Perry Wrote: When saving a model containing a flexible part, LDCad adds a "0 UNOFFICIAL_PART" line instead of the "0 !LDRAW_ORG" line required by the OMR.

(2020-08-19, 18:41)Roland Melkert Wrote: I'm wondering if the OMR needs to loosen its rules about this, as technically the flexible part is not (and will never be) managed by LDraw.org something the !LDRAW_ORG meta implies.

That said I could make it a main.cfg option.

(2020-08-20, 0:54)N. W. Perry Wrote: Yeah, it would make sense to have an exception for generated flexible parts, since the standard LDraw header doesn't have a category for those (though it does have a qualifier for flexible sections).

In a way, it's really more about having the OMR-checking programs not throw an error for flexible parts, or maybe allow it to the LDCad clean-up dialog, just to make MPDCenter happy.

(2020-08-24, 22:13)Lasse Deleuran Wrote: and I have stumbled on this parameter:

(2020-08-25, 18:37)Roland Melkert Wrote: Yes the documentation is a bit behind.

I added that option to prevent merging of segments with a too large of an roll difference.

It's the amount of degrees between the roll of two successive segments. If it's below the given value the two segments will be joined into a single (stretched) one.

Zero applies the default (hard-coded, version depended) threshold.

(2020-08-25, 20:15)Lasse Deleuran Wrote: Thanks of rthe quick clarification. So far this is the only parameter which raised a warning in the verifier that I am creating. But so far I have only tried to implement rubber bands and Power functions elements, so more might pop up.