Studio library inconsistencies

[N. W. Perry]

Thinking again about this post (from Philo) about Studio:

Is it possible to create an MPD embedding ALL official and unofficial parts? My use case is to render (or create BIs)  a model with Studio without fiddling with all part incompatibilities, libraries not in sync causing missing subparts and so on...
The complete scenario would be to embed all parts, add a prefix to avoid any conflict with existing Studio parts, extract these parts from MPD with MPDwizard, and place them in Studio CustomParts folder. After that, the model _should_ import flawlessly in Studio.

There are so many of these inconsistencies that when you have a really big build (like the Notre Dame cathedral I just finished), it can take quite a long time to adapt an LDraw model to Studio.

Remind me again, what's to prevent me from simply copying my entire LDraw folder in place of the one that comes with Studio, so that it always has the full library every time?

Or would it truly be better to try and embed all parts in an MPD, as Philo suggests?

[Orion Pobursky]

Remind me again, what's to prevent me from simply copying my entire LDraw folder in place of the one that comes with Studio, so that it always has the full library every time?

This is what I do. I put the entire library into CustomParts. The only side effect is that initial loading of Stud.io takes a little bit longer.

[N. W. Perry]

This is what I do. I put the entire library into CustomParts. The only side effect is that initial loading of Stud.io takes a little bit longer.

Does Studio prioritize custom parts over its main library, if the filename is duplicated?

[Sylvain Sauvage]

Does Studio prioritize custom parts over its main library, if the filename is duplicated?

No.  Stock files are prioritized.
You can test that by putting a random model in CustomParts and naming it 3001.dat: you’ll see a 2x4 brick.

And the copy in the Custom Parts palette will be categorized as a Brick.  That’s a good way to see if the part is now officially in Studio: it gets a category.  It’s also a problem because some parts (DUPLO) are in Studio’s database with no category (= category zero), and therefore don’t appear anywhere.

Also, the other solution of replacing Studio stock files is a bad idea because updates will corrupt the files (the update program, Patcher, uses binary diffs).

And, yes, Studio’s “ldraw” folder is a fine mess.  With duplicates in UnOfficial, and butchered LDraw files (latest seen is 10169: the original had been unnecessarily subfiled in 2019 and is now broken by the inclusion of the new patterned versions which use another subfiling).
That folder needs a good clean-up and update.
And the “database” (StudioPartDefinition2.txt) too.  And it also needs to be automatically updated when the catalogue is changed (parts re-IDed or renamed), but it’s not a priority.  The devs seem to prefer my nagging them every few days with a new correction to make 🤷‍♂️

[N. W. Perry]

Also, the other solution of replacing Studio stock files is a bad idea because updates will corrupt the files (the update program, Patcher, uses binary diffs).

Is it just a matter of having to re-replace the stock files after each update, or does the corruption go deeper than that?

[Sylvain Sauvage]

Is it just a matter of having to re-replace the stock files after each update, or does the corruption go deeper than that?

That can work… but you need to remember to do it