I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
The problem is that LDraw and LEGO do the opposite. So:
1. It makes it more complicated to include the parts in Studio as new files with
inverted colours need to be created (and that’s sometimes forgotten).
2. That makes Studio files (even more) incompatible with LDraw.
3. For each new BDP series, the palette has at least one part wrong because the
team gets the list of parts and colours from LEGO.
Yes, I know it won’t happen. And I’m three weeks late for it to be a joke but
I’m doing it anyway!
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
The problem is that LDraw and LEGO do the opposite. So:
1. It makes it more complicated to include the parts in Studio as new files with
inverted colours need to be created (and that’s sometimes forgotten).
2. That makes Studio files (even more) incompatible with LDraw.
3. For each new BDP series, the palette has at least one part wrong because the
team gets the list of parts and colours from LEGO.
Oh, and I forgot:
4. When the devs take 3D models from LEGO (instead of LDraw), the colours are
wrong.
That also goes for other parts but the hips&legs are really the worst offenders.
Yes, I know it won’t happen. And I’m three weeks late for it to be a joke but
I’m doing it anyway!
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
The problem is that LDraw and LEGO do the opposite. So:
1. It makes it more complicated to include the parts in Studio as new files with
inverted colours need to be created (and that’s sometimes forgotten).
2. That makes Studio files (even more) incompatible with LDraw.
3. For each new BDP series, the palette has at least one part wrong because the
team gets the list of parts and colours from LEGO.
Oh, and I forgot:
4. When the devs take 3D models from LEGO (instead of LDraw), the colours are
wrong.
That also goes for other parts but the hips&legs are really the worst offenders.
Also:
5. I need to explain to the users who report the issue.
6. I need to explain to the Studio and BDP teams….
Yes, I know it won’t happen. And I’m three weeks late for it to be a joke but
I’m doing it anyway!
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
Yah, I have never understood that. To me, the "base" part should be the
hips. The legs are attached to this base (the hips). The other way around doesn't
make sense. It should be the same as done with windows and glass - the window
is the base, the glass is then connected to it, not the other way around.
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
Yah, I have never understood that. To me, the "base" part should be the
hips. The legs are attached to this base (the hips). The other way around doesn't
make sense. It should be the same as done with windows and glass - the window
is the base, the glass is then connected to it, not the other way around.
Especially considering that leg assemblies are numbered 970c* and 970 is the
hips part:
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
Yah, I have never understood that. To me, the "base" part should be the
hips. The legs are attached to this base (the hips). The other way around doesn't
make sense. It should be the same as done with windows and glass - the window
is the base, the glass is then connected to it, not the other way around.
Niek.
The straw that broke the camel’s back tonight was this pair:
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
Yah, I have never understood that. To me, the "base" part should be the
hips. The legs are attached to this base (the hips). The other way around doesn't
make sense. It should be the same as done with windows and glass - the window
is the base, the glass is then connected to it, not the other way around.
Niek.
The straw that broke the camel’s back tonight was this pair:
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
The problem is that LDraw and LEGO do the opposite. So:
1. It makes it more complicated to include the parts in Studio as new files with
inverted colours need to be created (and that’s sometimes forgotten).
2. That makes Studio files (even more) incompatible with LDraw.
3. For each new BDP series, the palette has at least one part wrong because the
team gets the list of parts and colours from LEGO.
Yes, I know it won’t happen. And I’m three weeks late for it to be a joke but
I’m doing it anyway!
Where can I vote yes please?
Assuming the 970c00 can stay, it's currently only a few hundred parts to
be renumbered/cross referenced, doable I'd say.
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
The problem is that LDraw and LEGO do the opposite. So:
1. It makes it more complicated to include the parts in Studio as new files with
inverted colours need to be created (and that’s sometimes forgotten).
2. That makes Studio files (even more) incompatible with LDraw.
3. For each new BDP series, the palette has at least one part wrong because the
team gets the list of parts and colours from LEGO.
Yes, I know it won’t happen. And I’m three weeks late for it to be a joke but
I’m doing it anyway!
What I would like to see is a better integration of both databases together,
as of now seems the Studio one is just running to keep up with the catalog and
making quick links.
Wouldn't it be better if would see the Studio part files in each catalog
entry like the models in the gallery?
But regarding your request, I don't see it feasible changing almost 3000
entries in the catalog that are established in a particular way in the community
since long ago.
It seems the best is for the team to notice this problem and make a mirror part
for each... Or be able to link each model color used to a particular catalog
entry. Or one generic by default and a specific color to a different one.
[…]
What I would like to see is a better integration of both databases together,
as of now seems the Studio one is just running to keep up with the catalog and
making quick links.
You and me both, Sergio
Wouldn't it be better if would see the Studio part files in each catalog
entry like the models in the gallery?
Here, it’s more the catalogue that’s behind: the LDraw files we can see in the
“3D image” section on the parts’ pages aren’t the ones used by Studio and a lot
are missing and/or have not been updated in ages.
(Remember when they tried replacing all the parts images with Studio renders?
I don’t think anything was updated since.)
But regarding your request, I don't see it feasible changing almost 3000
entries in the catalog that are established in a particular way in the community
since long ago.
Yep, that’s why I said I knew it wouldn’t happen. Besides, other databases (Rebrickable)
are using the same convention as BL. So, even more impossible work.
But sometimes, one needs to vent
It seems the best is for the team to notice this problem and make a mirror part
for each...
That’s what they do… most of the time.
But some parts are missed or old errors are found.
Or be able to link each model color used to a particular catalog
entry. Or one generic by default and a specific color to a different one.
The main problem is that LDraw parts are like the catalogue entries: there’s
only one variable colour and all the other colours are fixed.
Any other change to Studio/BL than adopting LDraw’s convention makes Studio (and
the catalogue) incompatible with LDraw.
If you take the example I gave, 970c05pb01 & 970c07pb01, the only thing that
changes between the two is the colour of the legs.
In Studio, because of the catalogue entries, you need two 3D models, that you
both paint Black to match the known colours.
In LDraw, it’s only one file, 73200bp6v.dat, that you paint Red or Blue (and
the hips are always Black).
So, if you import into Studio an LDraw file with that part, you need to know
that the colour should always be Black and the BL ID should depend on the colour
of the part in LDraw.
And what happens if someone coloured the legs in Green in LDraw? No matching
BL ID, or a default one (that will always be the wrong one).
And, conversely, if you export your Studio file to the LDraw format, whatever
the colour of the part in Studio, you’d need to export it either as Blue or Red,
according the BL ID.
But then what should happen if you coloured the part (= hips) in Green? They
would always be Black in LDraw.
A whole new database would be needed to store the matches.
Of course, Studio just doesn’t care and uses its own files both ways. So it’s
always wrong.
A solution to always have the right colours in the models would be to break all
assemblies… but then you aren’t matching BL IDs anymore.
Now, another solution, that no one proposed yet, would simply be to have LDraw
adopt BL’s convention
I would strongly suggest that the catalogue change its convention for the hips
and legs parts.
As it is now, it’s a fixed colour for the legs and a variable colour for the
hips.
The problem is that LDraw and LEGO do the opposite. So:
1. It makes it more complicated to include the parts in Studio as new files with
inverted colours need to be created (and that’s sometimes forgotten).
2. That makes Studio files (even more) incompatible with LDraw.
3. For each new BDP series, the palette has at least one part wrong because the
team gets the list of parts and colours from LEGO.
Yes, I know it won’t happen. And I’m three weeks late for it to be a joke but
I’m doing it anyway!
White Legs with Black Hips
-------------------------------------
and rename the 654 decorated ones that are in the Catalog?
Logically, the base part here is the Hips. Lego tends to assign color to the
last part attached to any assembly. Their methods are about production and our
methods are about cataloging and organization.
Lego also lists Torso Assemblies by the hand color. Is this an issue as well?
White Legs with Black Hips
-------------------------------------
and rename the 654 decorated ones that are in the Catalog?
I don’t exactly “want” to. I just wish for a time machine to make LDraw and
BL agree on their conventions before anyone dug themself too deep….
Logically, the base part here is the Hips. Lego tends to assign color to the
last part attached to any assembly. Their methods are about production and our
methods are about cataloging and organization.
The main issue is with LDraw.
LEGO is just yet another source of troubles… and I believe that, whatever we
do, their data will always be troublesome
Lego also lists Torso Assemblies by the hand color. Is this an issue as well?
Not that I’ve seen 🤔
But then, AFAICT, the Studio devs only use LEGO data for BDP, and BDP is all
Yellow minifigures and no IP.
But other parts have the problem. Last one was 7096pb01 for which the Studio
devs used LEGO data (it’s not yet in LDraw)… and the colours are inverted (pink
with a variable tip) 🙄
*
7096pb01 Plant Plate, Round 1 x 2 with Pointed Leaf with Marbled White Pattern Parts: Plant
White Legs with Black Hips
-------------------------------------
and rename the 654 decorated ones that are in the Catalog?
I don’t exactly “want” to. I just wish for a time machine to make LDraw and
BL agree on their conventions before anyone dug themself too deep….
Logically, the base part here is the Hips. Lego tends to assign color to the
last part attached to any assembly. Their methods are about production and our
methods are about cataloging and organization.
The main issue is with LDraw.
LEGO is just yet another source of troubles… and I believe that, whatever we
do, their data will always be troublesome
Lego also lists Torso Assemblies by the hand color. Is this an issue as well?
Not that I’ve seen 🤔
But then, AFAICT, the Studio devs only use LEGO data for BDP, and BDP is all
Yellow minifigures and no IP.
But other parts have the problem. Last one was 7096pb01 for which the Studio
devs used LEGO data (it’s not yet in LDraw)… and the colours are inverted (pink
with a variable tip) 🙄
*
7096pb01 Plant Plate, Round 1 x 2 with Pointed Leaf with Marbled White Pattern Parts: Plant
Alrighty, I am going to logic this that perhaps the system that was designed
with its end purpose in mind should be the one we stick with. The Catalog has
a reason for the hips being the base color of this assembly. Changing it for
the sake of some other systems that were designed for other purposes ie production,
or just random computer coding choices doesn't seem like the right thing.
[…]
Alrighty, I am going to logic this that perhaps the system that was designed
with its end purpose in mind should be the one we stick with. The Catalog has
a reason for the hips being the base color of this assembly. Changing it for
the sake of some other systems that were designed for other purposes ie production,
or just random computer coding choices doesn't seem like the right thing.
~Jen
Well, as I said, I posted 3 weeks late. That is, I should have posted on the
1st 😉
I wasn’t expecting to be taken so seriously 😅 I mean, just rub two neurons
together and you see that, on any side, a change would mean a lot of work.
*sigh* The weight of history… 😁
[…]
Alrighty, I am going to logic this that perhaps the system that was designed
with its end purpose in mind should be the one we stick with. The Catalog has
a reason for the hips being the base color of this assembly. Changing it for
the sake of some other systems that were designed for other purposes ie production,
or just random computer coding choices doesn't seem like the right thing.
~Jen
Well, as I said, I posted 3 weeks late. That is, I should have posted on the
1st 😉
I wasn’t expecting to be taken so seriously 😅 I mean, just rub two neurons
together and you see that, on any side, a change would mean a lot of work.
*sigh* The weight of history… 😁
No worries! I am not familiar enough with Studio to grasp the magnitude of how
things like this create havoc over there. There's got to be some way to
code around the issue instead of changing something so big in the Catalog.
I hope someone figures it out.
France, Nouvelle-Aquitaine
Canada, Alberta
USA, New Jersey
Netherlands, Groningen
Spain, Comunidad Valenciana
