Are patterned parts allowed to deviate from the mesh of the unpatterned version?

It seems different authors have chosen different solutions. Some authors prefer using 5 decimals to make sure that the patterned part doesn't introduce new cond lines. Other authors find it perfectly acceptable to deviate from the unpatterned mesh and ignore the need for new cond lines.

Is there any consensus?
Are both approaches acceptable?
Is either approach preferable?
Why shouldn't the deviating mesh also require new cond lines?

How are texmap images reviewed? Is special software needed?

Is there a way to filter away the parts I have already voted on?

I'm looking for pieces 37073 - parted yellow hair
https://www.bricklink.com/v2/catalog/cat...#T=C&C=103
and piece 67900 - hare
 https://www.bricklink.com/v2/catalog/cat...#T=C&C=162

They are used in Hogwarts Room of Requirement set 75966. Neither are on http://www.digital-bricks.de/en/statistic4.php.

I've come across parts where the main file has been certified by two or more reviewers, but one of the subfiles has not. Sometimes the subfile tree is 5 levels deep and it's easy to miss an offshoot or a subfile that isn't referenced by the main file.

Does the parts tracker have a convenient feature where I can see how many subfiles a particular part has in its subfile tree or is the only way to click through the subfile dependencies?

There is an automatic hold for parts not having certified subparts, but is that info useful before an admin has made the admin review or a subpart has been graduated?

I have a problem with LPub3D rendering LDView with Enable Highlight Steps.


Parts with tan colour now appear transparent instead of just highlighting the edge colour.
https://photos.app.goo.gl/JfhVyvE7CVQzUPqE7

The root cause seems to be in LDConfig.ldr with this change:

0 !LDRAW_ORG Configuration UPDATE 2025-09-18
0 // Last update: Added 11015 Trans_White and 11019 Trans_Tan


LPub3D uses the prefix 110 to show the highlighted parts with a defined edge colour:

# File: LEGOFadeStepColorParts.lst  Generated on: 11-07-2025 19:53:40

# This space-delimited list captures the LDraw static color parts (and their subfiles) to support
# step fade and step highlight. Parts on this list are identified in the LDraw library and copied to
# their respective custom directory. Copied files are modified as described in the following
# lines. If fade step is enabled, color codes are replaced with a custom code using the standard
# color code prefixed with [100].

# If using a single fade step color, color codes are replaced with main material color
# code 16 using the fade color set in Preferences. If part highlight is enabled, edge
# color values are replaced with the color value set in Preferences. If part highlight is
# enabled, color codes are replaced with a custom code using the standard color code
# prefixed with [110].

# When fade step is enabled, custom generated files are appended with '-fade',
# for example, ...\custom\parts\99499-fade.dat                 

# When highlight step is enabled, custom generated files are appended with '-highlight',
# for example, ...\custom\parts\99499-highlight.dat                 


So LDView now finds the new colour 11019 in LDConfig.ldr to be Trans_Tan, instead of the local definition of LPub3D in the temporary file 42143 - 1.1.1.1-highlight.ldr:

0 !COLOUR LPub3D_Orange CODE 11025 VALUE #D67923 EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Dark_Azure CODE 110321 VALUE #469BC3 EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Yellow CODE 11014 VALUE #FAC80A EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Tan CODE 11019 VALUE #D7BA8C EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Light_Bluish_Grey CODE 11071 VALUE #969696 EDGE #C000FF00 ALPHA 255
0 !SILHOUETTE 1 #C000FF00
1 11071 0 0 0 -1 0 0 0 -1 0 0 0 1 64179.dat
1 11019 0 0 50 0 0 1 0 1 0 -1 0 0 3749.dat
1 11014 0 0 40 1 0 0 0 1 0 0 0 1 69762.dat
1 11014 0 0 -40 1 0 0 0 -1 0 0 0 -1 69762.dat
1 11019 0 0 -70 0 0 -1 0 1 0 1 0 0 99008.dat
1 110321 0 0 -80 1 0 0 0 -1 0 0 0 -1 69779.dat
1 11014 0 0 0 0 0 -1 0 1 0 1 0 0 42143 - 1.1.1.1.1-highlight.ldr
1 11014 -40 0 0 1 0 0 0 1 0 0 0 1 4519.dat
1 11014 -70 0 0 0 0 1 0 1 0 -1 0 0 59443.dat
1 11014 40 0 0 -1 0 0 0 1 0 0 0 -1 4519.dat
1 11014 70 0 0 0 0 -1 0 1 0 1 0 0 59443.dat
1 11025 40 0 -60 0 0 -1 1 0 0 0 -1 0 65304.dat
1 11025 -40 0 -60 0 0 -1 1 0 0 0 -1 0 65304.dat
0 !SILHOUETTE

How to solve this conflict?
Why has the colour 11019 been included in LDConfig.ldr ?
If I remove it there, the problem is solved.

When a part number is updated, a move to file is created for the old number. Why does the new part use the subfiles from the old part number?

e.g. https://library.ldraw.org/parts/49972

What is the position in regard to matching the colours of the BI textures vs the colours that say Bricklink say the colours are?

For example making part 3069pb1341
https://www.bricklink.com/v2/catalog/cat...#T=C&C=152

A) is the part in studio which uses the texture from BI

B) My go to match those colours

C) The colours if you go by the parts description in the Bricklink store.

So do we just ignore the actual texture colours and go with the store decription?

I'm considering implementing the following automatic upon submit edits:
- Remove all lines that consist of a single "0" and replace with a blank line
- Remove all lines that are "0 //" (i.e. a blank comment) and replace with a blank line
- If the last line is a single "0", remove completely
- Capitalize the first word for all keywords.

Thoughts?

Thread for Friends 2025 sets