Thinking about doing a LDCad 1.7 version

[Roland Melkert]

Which, I assume, would mean storing that string in a meta tag, or maybe as shadow content?

No I meant like
0.637276437432e-22
but 3 digits is considered 'normal' behaviour.

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!) 

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

[N. W. Perry]

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

…interesting. I think I'm at a good place for now, but will definitely keep this option in mind. 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?

[Roland Melkert]

I think I'm at a good place for now

Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision

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?

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.

[N. W. Perry]

Probably best you don't want to fall in the rabbit hole known as the wonderful world of floating point precision

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! 

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.

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

[Roland Melkert]

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

Only lines that where mutated during the editing of the file as LDCad preservers all lines it didn't change.

[N. W. Perry]

Hmm…what about a basic right triangle calculator? This is by far the most common calculation I make, to find the rotation angle of one part against a stationary surface. I don't know if it makes sense to add as part of the Selection Info tool, or perhaps as a macro. (This would probably be a perfect starter project if I ever decide to try some scripting!)

It would work like this—first you select three points:

• 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
  

   

Point C gives us the X-value of point A after it's rotated; we need to find its Y-value (in this case). Because we know two sides of a right triangle, we can find the third side length, and move point C by that amount in the Y-direction.

   

Now that A-B and B-C are the same length, we can get the rotation angle to translate A to C.

   

Of course the second part of this already exists; it's just a matter of solving the right triangle to get the second coordinate for the rotated point.

[Orion Pobursky]

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.

[N. W. Perry]

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.

Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning. 

[Roland Melkert]

Yep, I think so too. Like I said, the perfect starter project if I find myself with no other plates spinning. 

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

[Roland Melkert]

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.

[N. W. Perry]

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

[N. W. Perry]

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:
   

[Roland Melkert]

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.

[N. W. Perry]

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…

[Roland Melkert]

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.

[N. W. Perry]

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.

[Roland Melkert]

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.

[N. W. Perry]

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.

[Roland Melkert]

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.

[Milan Vančura]

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

[Roland Melkert]

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.

I know, but often when I start to work on documentation in about 5 minutes I'm like "Bored now"

Adding features trough script is a 2.0 core feature, as I want to keep the binary compact and do everything else trough extensions.

[Roland Melkert]

- !DATA support

Took some more work than expected but I have implemented basic support for embedded textures in 1.7

   

Next I will need to hide the DATA 'sub model' from the editor as it behaves as a empty model at the moment.

But I'm not yet sure how to handle the contents of data sections gui wise.

Any ideas on that are welcome.

I'm thinking to remove the whole "Change current session" menu and instead add a generic dialog from where you can save/add/change submodels/data content etc.

Only problem with that is when there is how to handle a mpd with just a single data section and nothing else (no editing area subject).

[Lasse Deleuran]

I have run into issues with a user who has used LDCad to create instructions with BUFEXCH commands, see: https://github.com/LasseD/buildinginstru.../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?

[N. W. Perry]

Thought of this one some time ago but didn't get around to suggesting it…

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

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.

[Roland Melkert]

I have run into issues with a user who has used LDCad to create instructions with BUFEXCH commands, see: https://github.com/LasseD/buildinginstru.../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?

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.

[Lasse Deleuran]

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.

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):

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.

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.

[Roland Melkert]

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.

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.

[Lasse Deleuran]

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.

That makes sense. I am not fully versed in when stuff is ghosted or not in MLCad, but if you add the "0" prefix then that should help with how LDView shows the model.

I will make sure that both "0 " and "0 GHOST " prefixes are ignored when interpreting the BUFEXCHG commands in the Javascript library, so it should work together with the output from LDCad no matter the version.

[Roland Melkert]

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

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 ?

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.

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

I assume you talking about these settings?

  props.png (Size: 5.79 KB / Downloads: 234)

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.

[N. W. Perry]

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 ?

Coordinate panel would be the perfect spot! I did know about the bin hint, but I'd forgotten about the document into icon. There's some helpful extra info in there, but as you say it requires switching to that part's editing session.

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

I assume you talking about these settings?

Yes, but now I can't replicate it either. Perhaps I was doing something wrong (like closing the dialog with ESC instead of ENTER).

But the other part is easy to replicate:
   

That's a bit of a funky number for LDU, no?

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.

Yes, 1.6d. And thanks for adding L, by the way—I use it all the time!

[Roland Melkert]

But the other part is easy to replicate:

Yes that's a bug, it is trying to format a double like an integer.

It's a presentation only issue, so no real corruption.

[Miguel Reizinho]

One other thing that I've thought of. When you hover over a part, status bar displays information about it. For example:

"Plate 1 x 2 (3023.dat) in Red (4,P) at 80; 117; -32"

But that info disappears once your mouse leaves the part even if that part is selected

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

And the config text file for the menu could be perhaps something like this:

(entry name) : (URL with var);
"Bricklink" : "https://www.bricklink.com/v2/catalog/catalogitem.page?P="&%part%"&#T=C";
Brickset : "https://brickset.com/parts/design-"&%part%;
Ldraw Part Tracker : "https://www.ldraw.org/parts/official-part-lookup.html?folder=parts&partid="&%part%

Do you think that would be possible/useful?

Best regards,

Miguel

[Milan Vančura]

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

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.

[Roland Melkert]

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.

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.

[Miguel Reizinho]

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.

If it helps, stud.io has a "table" of parts conversion from LDRAW to Bricklink. Inside folder "C:\Program Files\Studio 2.0\data" there's a file named "StudioPartDefinition2.txt". It's a TAB delimited file with several columns with useful information including BL ItemNo and LDraw ItemNo

[Lasse Deleuran]

Many OMR models have generated parts (hoses, cables, bands, etc.) and I can see the bulk of the generated MPD files are from the generated fallback content. 

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?

[Roland Melkert]

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?

The main used algorithm is bezier, second most used thing is interpolation of quaterions.

The meta's themselves are documented on my site and also on LDraw.org itself as it was proposed to become (the base of) a standard some time ago.

If you need some other details feel free to ask.

[N. W. Perry]

Perhaps this is simple, perhaps not…but 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. :-)

[Roland Melkert]

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. :-)

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.

[N. W. Perry]

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.

Yeah, I can see it being annoying if it were part of the undo/redo chain. I was picturing maybe a new fourth entry in the Select menu, as "All, None, Invert, Last" or some such. But maybe behind the scenes it's the same thing…

I could also just be more careful and not accidentally deselect a huge list of parts. :-)

[N. W. Perry]

Been meaning to mention this, and I can't remember if it's been brought up already:

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. It can be changed in the header dialog, but the change will be undone at the next save. I've gotten into the habit of fixing it manually now, but it does require that extra step when OMRizing (and if I end up saving the file in LDCad again, I often forget to re-fix it).

[Roland Melkert]

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.

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.

[N. W. Perry]

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.

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.

[Orion Pobursky]

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.

I don't feel the !LDRAW_ORG implies anything but file type.
Therefore 0 !LDRAW_ORG Unofficial_Model is fine.

[Lasse Deleuran]

Hi Roland,

I am enjoying my evenings trying to interpret the LDCad commands, and I have stumbled on this parameter:

segsMrgRollAng

It is not in the documentation ( http://www.melkert.net/LDCad/tech/meta ). Am I looking the right place?

[Roland Melkert]

and I have stumbled on this parameter:

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.

[Lasse Deleuran]

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.

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.

[Roland Melkert]

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.

If you are writing a parser you could also 'forget' about the 'refsDyn' setting as it has been depreciated (is changed to refsStat on load).

And there is also a new option for the donFinScale option, namely 'segMerge' which will compensate for the overlap while merging sections (otherwise you will loose the overlap altogether).

There might be more, I really need to update the documentation (I think it's still based on the 1.4 version).

Running all the default templates should reveal any missing things as I usually add things when I need them in a template