(2018-12-02, 21:22)Orion Pobursky Wrote: I read the CONTENT META. A couple of thoughts:The meta was initially setup to help LDCad choose a handler class for the subfile (model, part, spring, path, etc).
- The add fallback is probably not required since I think the generated (to use Travis's more precise terminology) content should always be added to the subfile.
- Since "fallback" isn't needed, is there a good way to fold the path and spring values into their respective metas? Or maybe a new meta for each?
To get this same effect we could also add a new type to !LDRAW_ORG, e.g.
0 !LDRAW_ORG Spring
and
0 !LDRAW_ORG Path
LDCad also expects a flexible subfile to be ether a spring or a path and it will basically ignore any other content.
The fallback property is mostly there to keep templates clean as those don't need the generated fallback code. And I was thinking sometimes you want to keep a mpd small by not including the flattened HQ fallback code. But in practice nobody uses this option.
I added the path and spring options to the CONTENT meta as it was there already anyway. We could move those options to dedicated !SPRING and !PATH metas .
If we do the above then we could leave the CONTENT meta out of the spec.
I also forgot to mention the GENERATED meta, I think this is what Travis is missing to understand the fallback approach.
An editor can use the SPRING/PATH matas to update the LDraw code after the GENERATED meta in a subfile.
Any normal LDraw viewer will knowingly or automatically ignore all the unknown metas and only process the normal content trailing GENERATED.
So LDView does not have to understand these metas at all, unless it wants to display higher quality versions of them.