Minifig Torso Shortcut Numbering and Questions

[Chris Böhnke]

All existing torsos should now have at least 1 assembly shortcut.

There are still ca. 54 possible combinations from existing files that could be made (and have a real counterpart), once numbering scheme is clear.

Note that this does NOT include plain torso assemblies or stickered ones.

973ph8 is still out there, but this one likely doesn't exist at all.

I am also sceptical towards the existence of this torso (which already has an assembly file):
https://library.ldraw.org/parts/14336

Can anyone confirm it's existence? I only know of the one with backprint...

[Chris Böhnke]

A few further things I noticed thus far:

1) Our current system produces mis-matches between the LDraw number system and the ones used on Bricklink, Rebrickable & co:

   

(Note: The 76382p47.dat is just a placeholder to explain the point. The actual Shortcut does currently not exist in LDraw)

2) There are a few torsos which exist in multiple colours. Usually this is no big deal, but occasionally this causes issues with LDraw pattern standards:


  royalknights.jpg (Size: 14.39 KB / Downloads: 30)

The crest should technically be colour 16 on different sides, depending on the base colour.
Another issue is the neck colour, which changes depending on base colour.

Are these minor details enough to cause a new file?

3) There is a torso assembly, we have not yet talked about: Design ID 73403 (https://brickset.com/parts/design-73403).

Torsos before 2006 never came in the form we currently have, but with pre-assembled heads:

  old.jpg (Size: 10.95 KB / Downloads: 30)

Whilst this has quite limited use, it is an official part... For inventory purposes, this might resolve some inconsistencies between the box piece count and actual piece count.

[Orion Pobursky]

1) Our current system produces mis-matches between the LDraw number system and the ones used on Bricklink, Rebrickable & co:

There are lots of mismatched part numbers. Most of the matches go back to when BL was using Peeron as a number source, now they do their own thing. Not super concerned about it

2) There are a few torsos which exist in multiple colours. Usually this is no big deal, but occasionally this causes issues with LDraw pattern standards:

The crest should technically be colour 16 on different sides, depending on the base colour.
Another issue is the neck colour, which changes depending on base colour.

Are these minor details enough to cause a new file?

For the former, is longs as it's visually correct, its not a problem
For the latter, neck mark differences don't matter

3) There is a torso assembly, we have not yet talked about: Design ID 73403 (https://brickset.com/parts/design-73403).
Torsos before 2006 never came in the form we currently have, but with pre-assembled heads:

Whilst this has quite limited use, it is an official part... For inventory purposes, this might resolve some inconsistencies between the box piece count and actual piece count.

Not super interested. We're a model building platform, not an inventory site. While those 2 things have a large amount of overlap I will take Willy's side on this and say a torso shortcut with head is a step too far and will just clutter the library.

[Orion Pobursky]

All existing torsos should now have at least 1 assembly shortcut.

There are still ca. 54 possible combinations from existing files that could be made (and have a real counterpart), once numbering scheme is clear.

Ok.  I thinks I'd like to switch to the pNNNN system for the rest and fill in the rest of the pXX(X) numbers when those torsos with the matching suffix are made.

But let's discuss.

[Chris Böhnke]

Ok.  I thinks I'd like to switch to the pNNNN system for the rest and fill in the rest of the pXX(X) numbers when those torsos with the matching suffix are made.

But let's discuss.

pNNNN sounds fine (also it was also already begun that way  ).

[Philippe Hurbain]

pNNNN sounds fine (also it was also already begun that way  ).

Yes, I started that yesterday