Part ID mismatches between Stud.io and BrickLink

[Kdapt-Preacher]

At some point in the last year or so, BrickLink (or possibly LDraw, or possibly both) have updated their ID numbers for some common parts. Most prominently, #3023 Plate 1x2 has split into 3023a and 3023b to reflect mold variants, but something similar has been done to #3069 Tile 1x2 and several other pieces as well. That's all well and good, but the result is that now my older Stud.io files that have all the 1x2 plates as just #3023 rather than #3023b can no longer be imported into BrickLink because it doesn't recognize the pieces. This is an issue because I've published several hundred MOCs on Rebrickable with Stud.io files for instructions and now I have people messaging me about the files being broken. I can fix this by going through every file manually and replacing all the existing parts with the new variants, but that would take days of work. Is there any way to convert them en masse, or to make BrickLink translate #3023 to #3023b automatically (which seems like how this ought to work, anyway)?

 

Thanks!

[SylvainLS]

More precisely:

— For 3023: LDraw made a new 3D model, they named it 3023b.dat and obsoleted 3023.dat.  Studio followed suit to allow the inclusion of decorated 3023.  Older models still reference 3023.dat, newer models correctly reference 3023b.dat.  Studio marks the “old” 3D models as “alternative LDraw model” in the Step List. The problem is that older models saved without modification in a newer Studio stupidly use “rename_3023.dat” and that breaks the .io upload on the website.

— For 3069 (and 3070 and 3068): BrickLink had 3069 (undetermined), 3069a (without groove) and 3069b (with groove).  That was confusing for buyers: 3069a are old and rare and expensive, sellers mostly didn’t use 3069 but 3069b.  So they decided to merge 3069 and 3069b, and to remove the confusing “with groove” as it’s the default, modern part and all the other tiles are all with groove and without the text in their description.  The LDraw 3D models weren’t changed.  The only visible effect in Studio was in the naming of the parts.  That shouldn’t impact loading, uploading, or parts lists, but maybe the website upload has problems with that too.

— Heads: BL merged 3626b, 3626c, and 28621 (all the hollow studs) into 3626, only 3626a (plain stud) remains as a variant.  That means that it has a mix of effect and non-effect.  For instance the plain parts 3626b and 3626c are now considered “alternative LDraw model,” because they are variant that are no longer recognized by BL.  For some decorated parts, it’s transparent because they didn’t have multiple 3D models, so only the BL ID changed.

— Slope 28192: For way too long, Studio had a 3D model that came from LDD.  It was slightly wrong and it caused problems when importing from / exporting to LDraw.  The 3D model was recently changed to the official LDraw model.  As the part’s default position and orientation changed, that messes up your older 3D models (only in Studio, not in Early Access, which is another pain).

— Ingot 99563: Studio used 96910.dat from LDD, now it uses 99563.dat.  It’s like 3023 but, AFAICT, with fewer problems.

And there were a few other parts that changed in the life of Studio (I remember the lantern, the 1x4x3 brick…).

 

Correcting “en masse”:

I made a small and ugly tool that can correct/modify parts in .io files: io_mod.html.

By default, it corrects 28192, 99563 and 3023.  It only works on recent .io files, and the files need to be saved again in Studio to be correct.  A bit more info here.

To use it:
— download this zip,
— unzip, open io_mod.html in a (recent) browser,
— open and force-save your files in Studio to be sure they are in latest version,
— feed the .io files to the tool,
— download all the generated mod_*.io files (no active link = something went wrong),
— open, check, and force-save them in Studio.
 

[Kdapt-Preacher]

12 hours ago, SylvainLS said:

Correcting “en masse”:

 

I made a small and ugly tool that can correct/modify parts in .io files: io_mod.html.

By default, it corrects 28192, 99563 and 3023.  It only works on recent .io files, and the files need to be saved again in Studio to be correct.  A bit more info here.

Ah, perfect--that's just what I needed. Odd that this is necessary, since it seems like something Studio could've addressed on their end more easily than requiring a third-party tool, but at least there's a solution. Thank you!