(unofficial) Part 7684 - broken in both LDView and MLCad

[tom alphin]

It looks fine on the LDraw website, but when I update my Unofficial parts library, it appears broken in both LDView and MLCad.  I have tried this on multiple Windows 11 amd64) devices.

Screenshot of part 7684 in both apps:


This is not a new issue, I probably noticed it 6 months ago, but was busy and didn't want to file a bug until I had repro'd the issue on a second PC.

---Tom

[tom alphin]

P.S. It is a new part for 2026, and since it is already in 3 sets and 3 different colors, it is ranked in 1029th place for the year.

[Orion Pobursky]

What, if anything, does the LDView error window show.

[Magnus Forsberg]

It looks like you don't have the correct version of the needed subfile s\64451s01.dat
It has been reworked and is now used in three parts: 64451, 11455, and in the new 7684.

   

[tom alphin]

It looks like you don't have the correct version of the needed subfile s\64451s01.dat
It has been reworked and is now used in three parts: 64451, 11455, and in the new 7684.

That is likely the problem, but I do not know why I would be in this situation. 

Why wouldn't I get that file automatically if I take the following install steps on a brand new PC:

1. Install x64 LDraw AIOI - LDraw_All-In-One-Installer_2026-01_setup_64Bit_v1
   
2. Install x32 LDraw AIOI - LDraw_Additional-Tools-Installer_2026-01_setup_32bit_v1
   
3. Launch LDView, File > Check for Library Updates
   
4. Download latest Unofficial parts from: https://library.ldraw.org/library/unoffi...rawunf.zip and unzip them to C:\Users\Public\Documents\LDraw\Unofficial
   
5. Launch MLCad, File > Scan Parts
   

That's a detailed explanation of my install routine on a new PC.

It's likely there is a problem in some step like "Check for Library Updates". If this were buggy, maybe it needs to be fixed at an installer or app level. It is also possible that, for some reason, those subparts aren't getting included in the Unofficial Parts .zip file.

Sincerely,
---Tom

P.S. if this isn't a part issue, we can move thread to a different forum.

[Orion Pobursky]

It's likely there is a problem in some step like "Check for Library Updates". If this were buggy, maybe it needs to be fixed at an installer or app level.  It is also possible that, for some reason, those subparts aren't getting included in the Unofficial Parts .zip file.

Try downloading the complete.zip from the latest update and replacing your LDraw directory with it's contents.  If that works then LDView isn't downloading updates as it should (which may be a problem with the LDraw server, LDView, or both).

[Gerald Lasser]

As the sub-part is an official part (but reworked) LDView is lacking this information.

The part in question and the common sub-part are still unoffical

LDView finds the old sub-part and uses it. It won't update.

[tom alphin]

1. I confirmed that my C:\Users\Public\Documents\LDraw\ folder matched the contents of complete.zip - and it matches exactly.
   
2. The next thing I confirmed is that the latest version of 64451s01.dat is in the C:\Users\Public\Documents\LDraw\Unofficial\Parts\s folder - It was correct and up to date.
   
3. Next, I manually overrode the version in C:\Users\Public\Documents\LDraw\parts\s to the newer version from the Unofficial folder, but it still did not work correctly.
   
4. Finally, I went into MLCad > file > Scan Parts, then added the part to the project file again - and it finally worked as expected in both MLCad and when exported from LDView.
   

Problem Statement:
LDView and MLCad do not (seem to) use the newer 'p' files from the Unofficial subfolder if that file exists in the official repository.

Potential Fixes:

1. Modify LDView and MLCad to use the unofficial subparts when they are newer than the official subpart.  (Likely not possible since MLCad is not being updated)
   
2. Reference a unique filename when a subpart needs to be modified to support an unofficial part.  ex: 64451s01_unoffical.dat  - This is likely a rare workaround. When part is brought into the official repo, the unofficial reference is removed when the subpart has been updated.
   
   
   

Thanks all,
---Tom

[Magnus Forsberg]

Problem Statement:
LDView and MLCad do not (seem to) use the newer 'p' files from the Unofficial subfolder if that file exists in the official repository.

Don't you mean the 's' files?

Somewhere a choice must be made: Should one or the other version of a file with the same name be used?
How does LdView handle that question?

I know from experince that MLCad doesn't handle it correctly. That's one of the reasons I stopped using it.

[tom alphin]

Don't you mean the 's' files?

Somewhere a choice must be made: Should one or the other version of a file with the same name be used?
How does LdView handle that question?

I know from experince that MLCad doesn't handle it correctly. That's one of the reasons I stopped using it.

Yes, I misspoke - I meant the 's' files.

LDView also handles it incorrectly - see previous photo. It uses the official one, even if a newer s/ file exists in the unofficial folder.

This is why I proposed a workaround, adding a postfix for the unofficial file, until it is merged into main.

[Travis Cobbs]

LDView also handles it incorrectly - see previous photo. It uses the official one, even if a newer s/ file exists in the unofficial folder.

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 this:

Code:

[LDraw]
BaseDirectory=C:\Lars\LDraw
[LDrawSearch]
1=<MODELDIR>
2=<UNOFFIC><HIDE><DEFPRIM><LDRAWDIR>\Unofficial\P
3=<UNOFFIC><DEFPART><LDRAWDIR>\Unofficial\PARTS
4=<HIDE><DEFPRIM><LDRAWDIR>\P
5=<DEFPART><LDRAWDIR>\PARTS
6=<LDRAWDIR>\MODELS

Note: The entire [LDraw] section may be optional, but if it's not, BaseDirectory needs to point to your LDraw directory.

I think that the above will only work if you don't have LDView configured to use an LDraw parts zip. Store the above text in a file named ldraw.ini in your LDraw directory.

Alternatively, the file can go in other platform-specific locations:

Windows: You can put the path to the file in an environment variable named LDRAWINI, or you can put the file in your USERPROFILE directory (typically C:\Users\<username>).

Non-Windows: Put the file in ~/.ldrawrc, ~/ldraw.ini.

[Magnus Forsberg]

I've solved it by constantly remove any official file that get a reworked version uploaded to the PT.
But I'm also a very active part author.

Another solution is to dump all unofficial files in the "official" file structure.

[tom alphin]

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

[Magnus Forsberg]

" in the rare case where a subpart in the "s/" folder needs to be modified ..."

I find it odd that you only have 1 part showing issues. We currently have ~400 sub-parts/files recycled on the PT.
As I see it, any recycled part will not be prestented correctly untill it is back in a new release.

[tom alphin]

I find it odd that you only have 1 part showing issues. We currently have ~400 sub-parts/files recycled on the PT.
As I see it, any recycled part will not be presented correctly until it is back in a new release.

🤷‍♂️ I'm honestly not sure why...

I suspect most of the subpart changes are subtle, and I simply have not noticed them for my use case - exporting part images from a single angled perspective for use in my labels and part guide.  It's important to my readers / users that I include brand new parts - which is why I need to use unofficial parts because it can take a long time for final parts to be approved.

s\64451s01.dat was significantly refactored as you noted yesterday. The image you provided clearly illustrated the significant change to the subpart design.  This made the changed subpart very visible.

[Orion Pobursky]

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.

We don't use any type of VCS for the library (yet).

I have several server modernization projects going at the moment and once those are stable, I'll pivot to moving the library to git.