I hate to bring up a topic that is 9 months old, but it seems that this never got a final conclusion.
I would agree with Roland in this post here https://forums.ldraw.org/thread-24490-po...l#pid41951 that the flow should be that the subfiles pulled from the library should NOT be over written by the subfiles within the MPD itself.
I have worked with a lot of cad programs and done a lot of modeling work, often using the basic structure concept of primitives in my own work making assemblies for manufacturing. Roland's approach is the most logical from a library perspective and it is how other cad packages handle similar circumstances.
I have seen several references to the OMR. I think that is a moot point because I seem to recall that all the parts must be part from the official library to be OMR compliant. This would mean that the use case for non-standard "stud.dat" would never be an issue there.
The issue comes up in testing new or altering existing parts. The new/altered parts ideally would be in a Development library that is referenced after the official and unofficial library locations.
This would be the ideal stack of libraries for a developer:
\p
\parts
\models
\Unofficial\p
\Unofficial\parts
\Development\p
\Development\parts
Then all programs would follow the order that the user chooses for the libraries. Then whichever is loaded LAST is ruling file. I say last because one of the leading CAD packages in the world, AutoCAD, has user loadable LISP files and if I have 4 files with a command call for "MAKEWALL", only the last loaded file that has the command "MAKEWALL" will work.
Also in AutoCAD, anything loaded in an Xref (cross reference) is never affected by the current file. There is a secondary type of reference that is called a Block. And Xref is always loaded from an outside source and a Block is local to the drawing. I can have the same block referenced in multiple files then Xref them into the current file. If the block definition is defined differently in the current file, it will not affect any Xref versions of the same block unless I go to each one and update it. Its not quite the same but the general concept is the same in that parts that are referenced into the current file should retain their reference paths but for new subfiles created within the current file, they should look to the MPD before the library.
Hopefully this rambling makes some sense.
I would agree with Roland in this post here https://forums.ldraw.org/thread-24490-po...l#pid41951 that the flow should be that the subfiles pulled from the library should NOT be over written by the subfiles within the MPD itself.
I have worked with a lot of cad programs and done a lot of modeling work, often using the basic structure concept of primitives in my own work making assemblies for manufacturing. Roland's approach is the most logical from a library perspective and it is how other cad packages handle similar circumstances.
I have seen several references to the OMR. I think that is a moot point because I seem to recall that all the parts must be part from the official library to be OMR compliant. This would mean that the use case for non-standard "stud.dat" would never be an issue there.
The issue comes up in testing new or altering existing parts. The new/altered parts ideally would be in a Development library that is referenced after the official and unofficial library locations.
This would be the ideal stack of libraries for a developer:
\p
\parts
\models
\Unofficial\p
\Unofficial\parts
\Development\p
\Development\parts
Then all programs would follow the order that the user chooses for the libraries. Then whichever is loaded LAST is ruling file. I say last because one of the leading CAD packages in the world, AutoCAD, has user loadable LISP files and if I have 4 files with a command call for "MAKEWALL", only the last loaded file that has the command "MAKEWALL" will work.
Also in AutoCAD, anything loaded in an Xref (cross reference) is never affected by the current file. There is a secondary type of reference that is called a Block. And Xref is always loaded from an outside source and a Block is local to the drawing. I can have the same block referenced in multiple files then Xref them into the current file. If the block definition is defined differently in the current file, it will not affect any Xref versions of the same block unless I go to each one and update it. Its not quite the same but the general concept is the same in that parts that are referenced into the current file should retain their reference paths but for new subfiles created within the current file, they should look to the MPD before the library.
Hopefully this rambling makes some sense.