LDCad 1.5 progress / opinions req

[Trevor Sandy]

In LDCad, out-of-the-box templates are all parts but, oddly, they are not persisted in the model as such.

I'm not sure what you mean here.

My apologies, when I refer to parts I was stupidly expecting files using the .dat extension. If I look in the LDraw "part" library official or unofficial, all part files, including the types part, subpart, primitive, 48_primitive, shortcut, alias, colour and all legacy file types, carry the .dat extension. As a result, I expected the LDraw template process to produce also a .dat file if it is the intention of the user to produce a part.

I expected .ldr files to be associated with models and submodels.

After you use a template to make a copy into a mpd it is still considered a part even though it uses the ldr extension. It is just listed in session panel list etc because it's editable not much unlike models are.

The "0 Unofficial part" line should tell a parser its a part no matter the extension or location. The line is commonly used in many files in the wild so it has become standard practice to do so. Even more so then using "0 !LDRAW_ORG Unofficial_Part" as that implies it is due to become part of the official library at some point.

I realize there are file type metas and I do code to take them into account when determining unofficial parts, but I find this approach to be less than ideal. Implementation of the file type meta seems to be without adherance to a standard so, as with LDCad, when an author uses a different meta format, I must manitain code to manage the mutation. For instruction generation, it is mainly important to distinguish between multi-component items that do not require part breakdow (i.e. parts) and those that do (i.e. models/submodels).

For me, saving a part (generated from a template) using the .dat extension enhances the human-readabilty (a key tenant of LDraw it seems) and offers an efficient alternative to unmanaged part type meta mutations.

For the substitution framework, I intend to use an alias table (like annotations currently) perhaps loaded into memory on startup as this approach will be independent of editors so someone editing with MLCad or whatever can also take advantage of alternative representations.

Maybe we should invent some sort of official alias meta for these kinds of generated parts?

I use MPDCenter as a reference as it is positioned to be the Ldraw "standard enforcer". MPDCenter has already defined Part/Unofficial_Part Alias as file types. As LDCad is the only LDraw template processor I know, perhaps it could be good to add this meta to the template part and include some reference to the master/static LDraw part id. On building the PLI, I chould check if the part is an alias representation and use its LDraw master in the PLI.

These are just my thoughts.

Cheers,

Trevor