LPub3D Unofficial parts in PLI

[Trevor Sandy]

I'll take a look. However, there is an alternative approach to substitutions via the part substitution list. You can see the list and instructions from the Configuration Menu (Edit PLI/BOM Substitute Parts List).

Cheeers,

I've looked at the substitution list before, but I'm afraid it won't work in this case. The motor is part of a template I inserted in LDCad. Templates are converted to MPD (sub)files and so each time you insert a template it could have a different name.

I added a BOM to the project and the unofficial parts don't turn up there either.

From my understanding LDCad templates are created with the name you define - or you can accept the default name proposed.  Therefore, you simply edit the substitute parts list file with the template name you defined as the default part and the shortcut or whatever representation you want as the alternate/substitute:

In this example the templates extension have been changed to .dat but this is not necessary to have the behaviour depicted.
   

I know very well this configuration. One may be likely to think that with the .ldr extension and 0 !LDRAW_ORG Unofficial_Model meta, the template is a model but, in fact, if you look at the source you will see it is also declared as a part with the meta 0 UNOFFICIAL PART; hence, why it automatically shows up in the LPub3D PLI.

I have been asking Roland for some time to consider allowing users the option to save a template with all the attributes of a part (i.e. .dat extension, 0 !LDRAW_ORG Unofficial_Part) but I understand this would conflict with the LDraw rules of 'unofficial' parts being parts that have not yet been approved. I can understand this position, even if I don't like it, so I have adapted LPub3D to recognize the 0 UNOFFICIAL PART meta; therefore, recognizing LDCad templates as parts (versus models) which they almost always are.

I could not reproduce your behaviour when I tested with 0 !LPUB PLI BEGIN SUB <part> <colour>/!LPUB PLI END metas. For me the behaviour was as expected.
   
   

Cheers,