(Yesterday, 16:17)Travis Cobbs Wrote: The current LDView behavior is by design, and this case obviously wasn't considered. I'm not sure if I'll try to fix it or not, because fixing it would likely introduce new problems. I believe that you can fix it locally by creating an ldraw.ini file that searches for unofficial parts and primitives before searching for official ones. It should look something like...
Travis, this is useful information, thanks for sharing.
I guess that I am still not sure why a process level workaround (like the "_unofficial" filename) wouldn't make sense in the rare case where a subpart in the "s/" folder needs to be modified to support a new part without breaking backwards compatibility with an existing part. This would be easy to manage with a git-style fork containing only the updated subpart and the small number of parts impacted by the change, but I do not think LDraw Parts Repo has branching capabilities.
The biggest point of confusion comes from the disconnect between what is shown on the website and what is shown in LDraw.
- Whatever script generates the preview image shown on the website uses the unofficial subparts (ex: https://library.ldraw.org/parts/50658 )
- The same part appears broken in LDView and MLCad, likely other apps as well.
---Tom