This is a part which was made back in 2009 but it has the wrong colour for the outer rectangle.

The part on the tracker it has the outer rectangle of the tile as black, the pictures of the part and the lego manual (for what that is worth) show the outer rectangle is red.

https://library.ldraw.org/parts/5276

https://img.bricklink.com/ItemImage/PN/6/3070px2.png

https://rebrickable.com/parts/3070bpr004...ots-print/

To be fair to the original author since lego were printing red on green it does sort of look dark brown in some pictures since lego suck at printing colours on other colours, and I guess that could have been mistaken for black. Or maybe there is a variant I don't know about? which is why I wanted to check first.

Thanks.

"This is managed by adding a single alpha character to the end of the base part number (e.g. 3626a.DAT and 3626a.DAT, the solid stud and hollow stud versions of the minifig head"

The second "3626a" should probably be "3626b".

Currently, part versioning is done by appending the part number with a letter. The same letters are also used when two designs have the same part number and when a bag contains multiple independent parts. This makes it impossible to automatically determine correct matches to e.g. external resources.

Having the links to external resources as separate meta is useful in particular when the external resources use different numbers or extensions. However, this doesn't solve the whole issue.

Can we begin using v2, v3, etc instead of b, c, d for cases when a "b/c/d replacement file" is created? This would enable all incorrect old versions of the part be available for backward compatibility, but allow new corrections to be distinguished from other uses.

I want to rotate the relative coordinates first and then do the displacement. Can I do this through a script?
I made some decorative parts using partdesign, but when I try to replace them with the original parts using LD, they're offset. I'd like to use a script to correct the position of specific parts, but I'm not sure how. Could someone write a script for the following example?

Attached Files

  41768mypaintpart.dat (Size: 112.74 KB / Downloads: 0)
  41768.dat (Size: 605 bytes / Downloads: 0)

I apologize if I sound like a catalog purist lol, but the Technic Axle and Pin Connector Triple (63869) needs a base model added. Right now the only part available in that mold has a sticker. Again I know how it sounds and I hope I don't get clowned on for asking this!

I found a thread from 2015 where connectivity was discussed. I also know that both stud.io and LDcad encode connectivity.

Would LDraw files benefit from having connectivity metadata?

There are a relatively small number of connection types. More than LDcad uses, but small enough to be enumerated.
Studs go into stud holders, antistuds go into antistud holders, clips (bar holders) can be radial or axial when attached to bars.

The majority of snapping connections can be described by a point and a direction vector, so effectively the same as a LDraw type 1 line. The type of connector can be in the subfile argument. If the connector types match and the directions vectors align, then the connection can snap into place, meaning that the points are made to overlap by adjusting one.

Sliding connectors (bars) need two points, which can be encoded as a point and a vector or similar to type 2 lines. Bar holders come in two flavors; those that attach radially (c-clips) and those that attach axially (o-clips and bar holes). The c-clips require another direction vector.

Hinge connectors also need a point and an axis of rotation, which can be encoded as a type 1 line. If an additional direction vector is available, then the hinge halves can be made to not overlap one another.

Ball connectors need a point and would benefit from knowing which way (direction) is definitively inappropriate (directional vectors must not overlap).

Many generic clipping connectors are adequately described by a single point.

Gears are a challenge, because there are two things to consider; the distance between rotational axes, and the toothing. Some gear pairs can connect slightly too close to each other and some gear pairs can connect very loosely without loosing function. So, snapping to a "perfect" distance is not an option. The software must calculate if any two gears interact or not.

As for the rotation, the minimum information is a point for the axis, an axial vector, and a reference point on the teethed perimeter.

Sometimes gears do not connect to other gears, but toothed shapes. The teethed path can be described by a set of line segments. The direction of the teeth can be described by a vector. The position of teeth relative to the line can be described by a reference point along that line.

The above is the information needed for each of the parts that interact. It is then up to the software to use that information to calculate the nature of the interaction.

Would someone be able to grab the new hair/hat molds and Zoro's mouth katana?

At first, I thought it was a helix, then maybe a half helix. It seems the shape is something not quite anything mathematical.
Is the mesh available from BI?

https://www.bricklink.com/v2/catalog/cat...P=54073px1

The part has a rectangular indentation on the handle. The injection point is on that rectangular area. Should the rectangular are be modeled or is it part of the injection point?

One end of the handle is intended to fit inside a hollow stud7. Is there a prim for it?

The LDraw.org main page shows "Parts Update 2025-07" instead of the 08 for the most recent package. The number of parts included appears correct.

LDConfig made from the one in the LDraw.org 2025-08 Parts Update.
This is a LDConfig file that includes the "Render Only" colours from Bricklink Studio.
(Without LUMINANCE values, I might change that in future updates)
To use it do the following:

1. Download it: 
     LDConfig_plus_bl_studio_colours.ldr (Size: 68.61 KB / Downloads: 4)
   
2. Move it to your LDraw folder
   
3. Rename "LDConfig.ldr" to LDConfig_default.ldr(or something else)
   
4. Rename "LDConfig_plus_bl_studio_colours.ldr" to "LDConfig.ldr"