Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | randyf  | | Posted: | Jan 13, 2019 17:05 | | Subject: | Re: Complete set of Unikitty CMFs? | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, chetzler writes:
| |
Is this supposed to be the entry for the complete set of 12 unique Unikitty collectible
minifigs? This whole entry is very confusing. The name says "complete random
set" and also "1 minifigure". The inventory shows 12 unique figs. Which is
it: a random set of 12? One random figure? A complete set of all the figs?
|
The entry above is for one random foil pack containing one random character,
thus the terms "Complete Random Set of 1 Minifigure". In the inventory, this
is represented by the "Or:" relationship and the Match ID of 1. That relationship
means you can get the first minifigure in the inventory *or* the second minifigure
in the inventory *or* the third minifigure in the inventory, etc., but not all
at once.
There are no official catalog entries for full sets of collectible minifigures.
Cheers,
Randy
|
 |
| Author: | chetzler | | Posted: | Jan 13, 2019 16:54 | | Subject: | Complete set of Unikitty CMFs? | | Viewed: | 109 times | | Topic: | Catalog | | Status: | Open | |
|
|
Is this supposed to be the entry for the complete set of 12 unique Unikitty collectible
minifigs? This whole entry is very confusing. The name says "complete random
set" and also "1 minifigure". The inventory shows 12 unique figs. Which is
it: a random set of 12? One random figure? A complete set of all the figs?
The price guide doesn't help much: the average prices seem too low for a
set of 12 and too high for a single fig. Judging by the individual prices it
appears that some sellers are treating this entry as a single random fig and
others are treating it as a a set of 12.
Am I better off creating a super lot if I want to sell a complete set of 12?
|
|
| Author: | axaday | | Posted: | Jan 13, 2019 16:31 | | Subject: | Re: Correct handling of 18904c01pb01 | | Viewed: | 29 times | | Topic: | Catalog | |
|
| In Catalog, normann1974 writes:
| | In Catalog, axaday writes:
| | In Catalog, normann1974 writes:
| | Please take a look at:
https://www.bricklink.com/catalogItemIn.asp?P=18904c01pb01&in=S
The crocodile consists of 4 parts and doesn't come assembled (at least not
in set 60157 which I just parted out). So isn't the correct way to include
the four parts in the inventories and the complete assembly as a counterpart
for all sets in the above list?
/Jan
|
You are correct. The pieces that come in the set should be included in the inventory
with the complete animal in the counterparts.
|
I'd love to fix this, but your response contradicts what two other admins
say in this thread. I'll let you all agree before I do anything.
/Jan
|
My response doesn't matter if the admins contradict it. But you will see
that Russell didn't exactly contradict me. He said they belong there, but
they just can't go there for the moment.
|
|
| Author: | normann1974 | | Posted: | Jan 13, 2019 15:00 | | Subject: | Re: Correct handling of 18904c01pb01 | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, axaday writes:
| | In Catalog, normann1974 writes:
| | Please take a look at:
https://www.bricklink.com/catalogItemIn.asp?P=18904c01pb01&in=S
The crocodile consists of 4 parts and doesn't come assembled (at least not
in set 60157 which I just parted out). So isn't the correct way to include
the four parts in the inventories and the complete assembly as a counterpart
for all sets in the above list?
/Jan
|
You are correct. The pieces that come in the set should be included in the inventory
with the complete animal in the counterparts.
|
I'd love to fix this, but your response contradicts what two other admins
say in this thread. I'll let you all agree before I do anything.
/Jan
|
|
|
| Author: | axaday | | Posted: | Jan 13, 2019 14:16 | | Subject: | Re: Correct handling of 18904c01pb01 | | Viewed: | 31 times | | Topic: | Catalog | |
|
| In Catalog, normann1974 writes:
| | Please take a look at:
https://www.bricklink.com/catalogItemIn.asp?P=18904c01pb01&in=S
The crocodile consists of 4 parts and doesn't come assembled (at least not
in set 60157 which I just parted out). So isn't the correct way to include
the four parts in the inventories and the complete assembly as a counterpart
for all sets in the above list?
/Jan
|
You are correct. The pieces that come in the set should be included in the inventory
with the complete animal in the counterparts.
|
|
| Author: | normann1974 | | Posted: | Jan 13, 2019 12:33 | | Subject: | Re: Correct handling of 18904c01pb01 | | Viewed: | 36 times | | Topic: | Catalog | |
|
| My question was not related to part-out but about consistency between the inventories.
Isn't that important?
/Jan
| | Unfortunately, counterparts don't display on the part-out page. Until that
is changed I think things like this must be left as is.
In Catalog, normann1974 writes:
| | Please take a look at:
https://www.bricklink.com/catalogItemIn.asp?P=18904c01pb01&in=S
The crocodile consists of 4 parts and doesn't come assembled (at least not
in set 60157 which I just parted out). So isn't the correct way to include
the four parts in the inventories and the complete assembly as a counterpart
for all sets in the above list?
/Jan
|
|
|
|
| Author: | tEoS | | Posted: | Jan 13, 2019 11:06 | | Subject: | Re: Correct handling of 18904c01pb01 | | Viewed: | 38 times | | Topic: | Catalog | |
|
| Unfortunately, counterparts don't display on the part-out page. Until that
is changed I think things like this must be left as is.
In Catalog, normann1974 writes:
| | Please take a look at:
https://www.bricklink.com/catalogItemIn.asp?P=18904c01pb01&in=S
The crocodile consists of 4 parts and doesn't come assembled (at least not
in set 60157 which I just parted out). So isn't the correct way to include
the four parts in the inventories and the complete assembly as a counterpart
for all sets in the above list?
/Jan
|
|
|
| Author: | normann1974 | | Posted: | Jan 13, 2019 10:06 | | Subject: | Correct handling of 18904c01pb01 | | Viewed: | 106 times | | Topic: | Catalog | | Status: | Open | |
|
| Please take a look at:
https://www.bricklink.com/catalogItemIn.asp?P=18904c01pb01&in=S
The crocodile consists of 4 parts and doesn't come assembled (at least not
in set 60157 which I just parted out). So isn't the correct way to include
the four parts in the inventories and the complete assembly as a counterpart
for all sets in the above list?
/Jan
|
| Author: | DarylB | | Posted: | Jan 12, 2019 12:34 | | Subject: | New items not in the catalogue | | Viewed: | 119 times | | Topic: | Catalog | | Status: | Open | |
|
| Please could you tell me how to add new items to the catalogue, in particular
how to allocate a 'pb' number to the part number for parts that are printed
or stickered. Thank you. Regards Daryl.
|
| Author: | BigBBricks | | Posted: | Jan 10, 2019 20:28 | | Subject: | Re: Please approve 30572-1 | | Viewed: | 56 times | | Topic: | Catalog | |
|
| In Catalog, Classicsmiley writes:
| | In Catalog, BigBBricks writes:
| | Please approve , it is currently on sale and image is available.
|
|
Thank you!
|
| Author: | Classicsmiley | | Posted: | Jan 10, 2019 20:01 | | Subject: | Re: Please approve 30572-1 | | Viewed: | 57 times | | Topic: | Catalog | |
|
| In Catalog, BigBBricks writes:
| | Please approve , it is currently on sale and image is available.
|
|
| Author: | BigBBricks | | Posted: | Jan 10, 2019 19:19 | | Subject: | Please approve 30572-1 | | Viewed: | 85 times | | Topic: | Catalog | | Status: | Open | |
|
| | Please approve 30572-1, it is currently on sale and image is available. |
| Author: | 0to60 | | Posted: | Jan 10, 2019 09:36 | | Subject: | Board game die complete assembly | | Viewed: | 72 times | | Topic: | Catalog | | Status: | Open | |
|
| Is there a way to list 64776 Board Game Die as a complete assembly with all 6
tiles rather than list 7 items separately?
Thanks
|
| Author: | Biglesdug | | Posted: | Jan 9, 2019 12:40 | | Subject: | Re: Minifig Complete with Alternate head? | | Viewed: | 32 times | | Topic: | Catalog | |
|
| | It's complete but I would advise noting it in the listing. |
|
| Author: | Brickwilbo | | Posted: | Jan 9, 2019 11:40 | | Subject: | Re: Minifig Complete with Alternate head? | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, runner.caller writes:
| | Hello,
Let's say a minifig is inventoried with a b-blocked style head.
Would a minifig assembly be considered complete if it has the alternate head
c-hollow style given that the this style head is technically only an alternate
part for the set inventory that the minifig came in and not the minifig itself.
Some minifig entries have a note saying something like: "This minifigure has
been found with both the 'b' and 'c' style head."
I would consider it complete, but I could see an OCD collector expecting the
'correct' head style per the BL figure assembly. Even if 'correct'
is just arbitrarily which ever style was found by the first user when adding
to the catalog.
Obviously, this only applies to figures produced during the great transition
period.
|
It is complete if it can come with an alternate head.
|
|
| Author: | runner.caller | | Posted: | Jan 9, 2019 11:33 | | Subject: | Minifig Complete with Alternate head? | | Viewed: | 72 times | | Topic: | Catalog | | Status: | Open | |
|
| Hello,
Let's say a minifig is inventoried with a b-blocked style head.
Would a minifig assembly be considered complete if it has the alternate head
c-hollow style given that the this style head is technically only an alternate
part for the set inventory that the minifig came in and not the minifig itself.
Some minifig entries have a note saying something like: "This minifigure has
been found with both the 'b' and 'c' style head."
I would consider it complete, but I could see an OCD collector expecting the
'correct' head style per the BL figure assembly. Even if 'correct'
is just arbitrarily which ever style was found by the first user when adding
to the catalog.
Obviously, this only applies to figures produced during the great transition
period.
|
|
| Author: | mfav | | Posted: | Jan 9, 2019 09:45 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 52 times | | Topic: | Catalog | |
|
| | | Sometimes the large image space is empty depending on the device you are using.
I notice this when using my phone, and people have reported similar problems
with tablets. That is a bug and I'll write it up if I can reproduce it. I
suspect it is a cache issue.
|
I think some value is not being consistently passed to the javascript controlling
that display, especially when the page loads. The image shows up more consistently
if it HAS been cached.
|
|
| Author: | yorbrick | | Posted: | Jan 8, 2019 05:36 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 23 times | | Topic: | Catalog | |
|
| When it comes to organizing or perhaps just displaying heads, I'd prefer
to see one change more than any other: show both/all stud types together. So
if someone clicks on the inventory of a minifigure, and then on the head, they
are shown all stud variants of that head print. It could be done that you need
to turn on all variants with a click-box if the default is just the one in the
catalogue, or turn off if on is the default and you want only the variant as
entered in the catalogue.
For many people, stud types don't matter. However, checking to see if other
stud types are available and what their cost is is a real faff.
Similarly, it should work for wants lists too.
|
|
| Author: | yorbrick | | Posted: | Jan 8, 2019 05:32 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 21 times | | Topic: | Catalog | |
|
| Rules need to be written tighter.
The fish bowl piece has a face. It is not used as a head, but I can still see
a fish face on it.
|
| Author: | StormChaser | | Posted: | Jan 7, 2019 22:27 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 28 times | | Topic: | Catalog | |
|
| In General, mfav writes:
| | I would like to suggest the following catalog guidelines for minifig head
|
Is it too much to ask that we keep this all in one thread where I can easily
reference it? I don't mind reposting everyone's replies to the original
thread and I can go on doing it as long as need be, but it is taking time away
from approving new catalog entries which I was working on.
|
|
| Author: | hpoort | | Posted: | Jan 7, 2019 22:19 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 25 times | | Topic: | Catalog | |
|
| | | 3. Fixed values: head, pattern
- I expect some shrieking about the pattern attribute, but if all decorated pieces
are separated from plain pieces at the category level, the need for "pattern"
as an identifier becomes moot. Thus "pattern" can be used to distinguish between
a "head" and a "not-head".
|
Definitely shrieking. The word "pattern" is used throughout the entire catalog
to distinguish plain and decorated items. For most searches, the category attribute
is not used nor visible. Hence, in the current database configuration, the word
"pattern" is still essential.
There are things to say for changing this database structure, but as you know,
that is out of our CA's control.
Hans-Peter
|
|
| Author: | mfav | | Posted: | Jan 7, 2019 22:08 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In General, axaday writes:
| | The trophy piece can be a minifig or a untensil depending on its print.
|
One solution: suggest that this piece get its own category where it is neither
minifig nor utensil. 3626 has its own category.
| | Similarly, I don't know why a "head" that is a fishbowl can't be a decorated round brick. Or is that regressive?
|
Minifig, head is a BL designation. As such, it's arbitrary.
Whether splitting the piece across different categories is desirable or not is
debatable. Whether or not that can be implemented within the current database
schema is a question. If the trophy piece already operates this way, then I wouldn't
have an objection. Others might.
I have supported the concept that certain parts be found wherever it makes sense
(multiple categories) and not be restricted to a single category. I believe it
requires changing a field at the db level to accomplish that. Example:
being additionally classified under vehicle, mudguard.
It might also imply some adjustment on the part of sellers to modify their systems
to accommodate.
|
|
| Author: | axaday | | Posted: | Jan 7, 2019 21:29 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 33 times | | Topic: | Catalog | |
|
| The trophy piece can be a minifig or a untensil depending on its print. Similarly,
I don't know why a "head" that is a fishbowl can't be a decorated round
brick. Or is that regressive?
In General, mfav writes:
| | I would like to suggest the following catalog guidelines for minifig head part
3626.
issues
1. Need to distinguish between 1-sided print and 2-sided print
2. Need to distinguish between things with faces and things without faces.
- 2.1 Need to distinguish between things with 1 face and things with 2 faces.
3. Need to distinguish between things that are heads and things that are not
heads.
4. Want to note stud type.
5. Need to note identifying attributes.
methodology
1. Fixed values: 1-sided print, 2-sided print.
- Might consider another value (top-print) for things like Avatar heads which
are printed around the stud. Or maybe not necessary and could be noted in attributes.
Anyway, fixed values here to aid search.
2. Fixed values: single-faced, dual-faced, no-face.
3. Fixed values: head, pattern
- I expect some shrieking about the pattern attribute, but if all decorated pieces
are separated from plain pieces at the category level, the need for "pattern"
as an identifier becomes moot. Thus "pattern" can be used to distinguish between
a "head" and a "not-head".
4. Existing scheme (blocked open, hollow, solid) seems satisfactory
5. Attributes should be considered by their side count and face count and presented
consistently. For any single-sided piece a straight description is fine. For
faces, I'd recommend a top-down scheme for consistency: hair, eyebrows, eyes,
mouth, scars/marks, whiskers. For two-sided, single-faced heads I'd start
with the character name if it exists, followed by Front, followed by Back. For
two-faced heads I'd start with the character name if it exists, followed
by side1 attributes, separate with a slash, side2 attributes. Color values would
precede attributes in "readable English" fashion, thus "brown hair" and not "hair,
brown".
Complete naming convention would be sequenced as follows: Attributes, Sides,
Faces, Type, Stud. This sequencing allows for the unique traits to
appear first, which is likely preferable to having those listed last for a number
of reasons.
2-side, 1-face Example:
Green Goblin. Front: Balaclava, Heavy brown eyebrows, black eyes white highlight,
smirk, dimples, cleft chin. Back: three black scalloped lines blue highlight.
2-sided print, single-faced head, blocked open stud.
2-side, 2-face Example:
Robot. Silver eyebrows, Lime eyes white highlight, clenched teeth, scuffs, rivets
/ Silver eyebrows, lime eyes white highlight, closed mouth, scuffs, rivets. 2-sided
print, dual-faced head, hollow stud.
Note 1: I have a personal prejudice against labelling every head that is not
"human" as "alien". I'd prefer to see additional terms such as "robot" and
perhaps "animal" where appropriate; these terms would also facilitate search.
Note 2: It would facilitate consistent data entry to have a part-specific data
entry form available on the site. The form would include any fixed values as
popup or radio selectors, generous fields for entry of attributes, and an image
or images with callouts to provide visual assistance and reference for the contributor.
Guidelines for data entry should be included on the form itself and not require
leaving the form to locate guideline information elsewhere.
Visualization attached.
|
|
|
| Author: | mfav | | Posted: | Jan 7, 2019 20:04 | | Subject: | Catalog Guidelines: Minifig Heads | | Viewed: | 96 times | | Topic: | Catalog | | Status: | Open | |
|
| I would like to suggest the following catalog guidelines for minifig head part
3626.
issues
1. Need to distinguish between 1-sided print and 2-sided print
2. Need to distinguish between things with faces and things without faces.
- 2.1 Need to distinguish between things with 1 face and things with 2 faces.
3. Need to distinguish between things that are heads and things that are not
heads.
4. Want to note stud type.
5. Need to note identifying attributes.
methodology
1. Fixed values: 1-sided print, 2-sided print.
- Might consider another value (top-print) for things like Avatar heads which
are printed around the stud. Or maybe not necessary and could be noted in attributes.
Anyway, fixed values here to aid search.
2. Fixed values: single-faced, dual-faced, no-face.
3. Fixed values: head, pattern
- I expect some shrieking about the pattern attribute, but if all decorated pieces
are separated from plain pieces at the category level, the need for "pattern"
as an identifier becomes moot. Thus "pattern" can be used to distinguish between
a "head" and a "not-head".
4. Existing scheme (blocked open, hollow, solid) seems satisfactory
5. Attributes should be considered by their side count and face count and presented
consistently. For any single-sided piece a straight description is fine. For
faces, I'd recommend a top-down scheme for consistency: hair, eyebrows, eyes,
mouth, scars/marks, whiskers. For two-sided, single-faced heads I'd start
with the character name if it exists, followed by Front, followed by Back. For
two-faced heads I'd start with the character name if it exists, followed
by side1 attributes, separate with a slash, side2 attributes. Color values would
precede attributes in "readable English" fashion, thus "brown hair" and not "hair,
brown".
Complete naming convention would be sequenced as follows: Attributes, Sides,
Faces, Type, Stud. This sequencing allows for the unique traits to
appear first, which is likely preferable to having those listed last for a number
of reasons.
2-side, 1-face Example:
Green Goblin. Front: Balaclava, Heavy brown eyebrows, black eyes white highlight,
smirk, dimples, cleft chin. Back: three black scalloped lines blue highlight.
2-sided print, single-faced head, blocked open stud.
2-side, 2-face Example:
Robot. Silver eyebrows, Lime eyes white highlight, clenched teeth, scuffs, rivets
/ Silver eyebrows, lime eyes white highlight, closed mouth, scuffs, rivets. 2-sided
print, dual-faced head, hollow stud.
Note 1: I have a personal prejudice against labelling every head that is not
"human" as "alien". I'd prefer to see additional terms such as "robot" and
perhaps "animal" where appropriate; these terms would also facilitate search.
Note 2: It would facilitate consistent data entry to have a part-specific data
entry form available on the site. The form would include any fixed values as
popup or radio selectors, generous fields for entry of attributes, and an image
or images with callouts to provide visual assistance and reference for the contributor.
Guidelines for data entry should be included on the form itself and not require
leaving the form to locate guideline information elsewhere.
Visualization attached.
|
|
|
| Author: | mfav | | Posted: | Jan 7, 2019 12:24 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 56 times | | Topic: | Catalog | |
|
| Thank you for taking the time to respond.
| | When this copy script was run (this was a one-time function), the credit was NOT transferred.
|
Oi. That makes for some busywork for somebody.
| | The whole rationale behind this image unification is because the management does not like the disconnect between a thumbnail image that shows one thing and a large image that shows another.
|
Woo-hoo management! Good call.
| | So right now, all catalog detail pages of those printed leg parts will show your
username under both small and large credits. But when the large image credit
slot is replaced by the additional credit slot, then the person who submitted
the primary additional image (the "default" additional image, if you will) will
have their username there instead, in cases where there is an additional image.
|
I don't know what the plan for this business is going forward, but it still
sounds problematic to me. I'd think you'd just have a single gallery
per contributor of images submitted, and credit the image in the popup window
alongside the image and eliminate all these other ambiguous and confusing and
possibly wrong attributions elsewhere.
| | It's hard for me to understand why an image of yours would get rejected, but it does appear that in each of these cases, your small image (80 x 60) was approved but your full size one wasn't.
|
No big deal. Can't expect everything to be accepted.
| | The second thing that has changed is that high quality images with a white background are greatly preferred over standard shots.
|
Although I'm not sure of the definition of "standard shot" is quantified
here, I believe this was always the case. The language I believe you should use,
if you want to describe this for future photo takers is: "silhouetted against
white". A piece of paper is white, and lots of objects are shot against that,
but the background in those shots I don't believe is what you're preferring.
| | Nice images were always appreciated, but the emphasis was on correctness, not visual appeal.
|
As we're seeing in some current threads, "correctness" is subject to revision
and whim.
| | So for example, the first minifig on the list currently has a large image showing
the neckpiece removed from the minifigure so as to show the printing on the torso.
In the past it was considered more desirable to be explicit about all details
of the figure,
|
This is not at all defined. What is more explicit: showing a minifig with a decorated
torso covered by a chest piece, or showing the torso? You can't show both
states at once. But explicit detail implies that you do need to know both states.
I'd think the emphasis should be on accurately describing the item in question
without ambiguity and within reason, according to a set of established guidelines.
In the case of minifigs, in the past, I believe that there was a preference for
a full-frontal image, and/or a full-frontal with a head inset if the face was
obscured by a visor or mask or something. In my case, if a figure has a backpack
or air tanks or similar, I try to make a 3/4 view where this element is apparent.
In the case of some divers with flippers, I positioned the figure such that the
flippers were very apparent. I'm sure some of these were not accepted because
they weren't full-frontals, even though they did more accurately completely
describe the figure.
Additional information can be conveyed with additional imagery, presumably accessed
via the image popup. Thumbnail imagery, though, should be simplified to the extent
that it can be while maintaining the most communicative immediacy possible at
a small size. In other words: the busier the thumbnails are, the more difficult
they are to recognize without effort.
| | but now the emphasis is on a presentation of the minifigure that will help sell it to today’s consumer.
|
The problem...don't know that that's the right word...maybe I can rephrase.
The definition of consumer is in question. There are lots of consumers. Some
consumers just want to buy a Darth Vader. Other consumers want to be able to
identify which Darth Vader, with a specific pattern and a specific head which
may be obscured by a helmet and so on. To one consumer the detail is irrelevant,
to another it's absolutely critical.
So, that in mind.
1. I don't believe it's possible, in many many instances, to create a
single image that meets the needs of both ends of the consumer spectrum.
2. Head insets and such do detract aesthetically and potentially introduce some
level of confusion.
3. Multiple-side collage images (front and back shown, also sometimes with an
inset) don't read well at small sizes. Take a look at any of the small black
torso images where there are front and back shown together. Those are dad-gum
near impossible to distinguish from one another. As thumbnails they fail to communicate
adequately.
4. Multiple side images may be misinterpreted as a "pair" of items and not "two
sides of a single item" kind of thing.
Trying to create an acceptable image in the absence of an "image codex"...particularly
in the case of minifigs...is challenging. A definitive set of guidelines would
be appreciated. Also, having the multiple images display in the popup is a step
in the right direction for the for the more hyper-aware customer.
In general, aesthetically, I'd like to see a 3/4 angle on minifigures become
the preferred angle. Here's why:
1. As time goes on, LEGO is incorporating more detail into some figures. Side
details on legs and arms become visible in 3/4 view.
2. Around-the-neck items like backpacks and airtanks can be more clearly shown
in a 3/4 view. Example: with full-frontal shots it's impossible, or nearly
so, to distinguish between an M:Tron fig with tanks and the same fig without.
3. From a technical standpoint, there are a lot of images in the gallery which
are shot either with a flash or the light positioned directly in front and slightly
above the image. This creates a strong white highlight on the top side of the
rounded part of the minifig legs (and sometimes in the middle of the face) and
obscures detail in those parts of the image. A 3/4 position would likely reflect
the light other than directly into the lens of the camera. The instruction to
turn the figure 30 degrees counterclockwise is easier to explain to non-technical
shooters than how to properly position lights, adjust exposure times, turn off
the flash, and the myriad other things one might do to improve the image.
4. Lego, as shiny plastic, can be particularly difficult to photograph well because
the surface is highly reflective. TLG itself tends to "paint out" reflections
in their promotional materials because of this. Any things that can be done to
reduce reflection and glare in the imagery is likely to make the image more communicative.
5. The "emphasis is on a presentation of the minifigure that will help sell it
to today’s consumer" here is being considered without context, and the context
should be an improved user interface sitewide, if greater sales are a goal. A
prettier set of thumbnails alone aren't going to be enough.
| | So in short, we think that your previously rejected images would stand a good
chance of being accepted today. And when in comes to parts, you have many, many
80 x 60 images in the BL system that could easily be upgraded to a larger size.
|
That comment elicits a chuckle from this end. "Easily" meaning I spend hours
combing through the archive to locate, extract, and upload them to BL. I appreciate
what I believe is the intended sentiment here, but, yeah. No. Not the top of
my priority list this week.
| | I understand the concern about mismanagement of images. But the site has actually not lost anything or corrupted it.
|
This is a matter of perspective. Or semantics. From my perspective, having one
contributor's content being credited to another constitutes corruption. When
the script ran that merged the two sets of images and the attribution was not
transferred, that constitutes corruption. The implication that you can correct
the situation eventually may be intended as reassurance, but (I'm going to
use metaphor here) in the immortal words of Cuba Gooding, Jr. "Show me the money."
| | If anything, we need to update the way credits are shown,
|
Yes.
| | and make sure that contributors know exactly why an image is rejected.
|
That would certainly be helpful and much appreciated.
|
|
| Author: | Teup | | Posted: | Jan 7, 2019 08:57 | | Subject: | Re: New Part Category | | Viewed: | 47 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | Today I added a new category: Wheel, Accessory.
I moved 31 parts from Wheel to the new category.
|
That's a nice idea, thanks! And don't have to move anything around in
my alphabetical storage either 
|
|
| Author: | Admin_Russell | | Posted: | Jan 7, 2019 02:21 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 130 times | | Topic: | Catalog | |
|
|
BrickLink
ID CardAdmin_Russell
|
Location:  USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
 |
Admin |
|
|
| BrickLink Administrator |
|
| In Catalog, mfav writes:
| | Well, now I can understand why the StormChaser is confused.
If the large image slot is going away, and the large images are going to then
slot into what now is the small slot...
...and I get keeping the small slot because the small slot had ALL colors of
a piece where the large slot typically had one "representative" image per piece
and not per color...
...then I think the solution would be to leave the small images as they were
(as those were the large images slotted down into the small slot) and change
the credit to the appropriate contributor.
If I understand the plan, which I may not, and apparently is also not clear to
more than just me, the plan is to replace all the small images with large images
as they become available. You're keeping the small slot because that slot
is already prepped to contain multiple colors of a piece where the large slot
is not...and you have small images of more pieces than you have large images.
I imagine that you'd lose ~70% of the images if you kept the large set and
abandoned the small set...because you don't have all colors in the large
set.
Right? So I can see the logic of that strategy.
|
Yes. Essentially, that is it.
| | Still.
That leaves me with these questions:
1. Why plug my small images back into the small slot? Why not leave the large-image-put-into-the-small-slot
(as this is the goal) and change the contributor? Seems like you're going
to have to go back and do that at some point.
|
There are two different banks of "small" images. There is the original bank which
contains your small images, and this is where the credit on those minifig small
images came from. The images from this bank still show up in Forum macro tags
and other older pages. They are fixed at 80 x 60, and we have no mechanism to
change them, other than if we reupload an image as the main image, and then new
thumbnail will be written over the old one.
The other bank of "small" images can be larger than even the original "large"
image, and the original "large" image was copied into this slot in the case of
minifigs, sets, etc. (basically, anything that could not have images in multiple
colors). When this copy script was run (this was a one-time function), the credit
was NOT transferred.
In cases where the large and small image were the same, or the large and small
images both had the same contributor, there was (and is) no attribution issue.
But there is an issue with large/small pairs that had different contributors.
And fortunately that is not typical.
The whole rationale behind this image unification is because the management does
not like the disconnect between a thumbnail image that shows one thing and a
large image that shows another. It is fine to have a thumbnail that shows only
a portion of the large image. But jumping to an entirely new image is considered
non-standard and distasteful.
| | 2. All the legs images in question are recent contributions, and while they may
have slotted into the small slot correctly, that doesn't answer why the large
images are getting mis-attributed. And will the mis-attribution continue?
|
There is no attribution issue with the legs images. You are just interpreting
the credits wrongly. However, because your images are in almost every case superior
to what we have, and because we prefer photos for printed parts, I uploaded your
images to both the old and the new slot and put all other images in the additional
images slot.
So right now, all catalog detail pages of those printed leg parts will show your
username under both small and large credits. But when the large image credit
slot is replaced by the additional credit slot, then the person who submitted
the primary additional image (the "default" additional image, if you will) will
have their username there instead, in cases where there is an additional image.
| | 3. Are there other images in the system that are similarly mis-attributed?
|
As I mentioned in another post, there are thousands of images attributed to "Admin"
that belong to other people. We change the credit when they are claimed.
Other than that, I am sure there are plenty of cases where someone helped another
upload an image and the credit never got correctly assigned. Or sometimes a user
tweaks an image an reuploads it under their account - normally in that situation
we will credit the original user, but I'm sure there have been cases where
it didn't happen.
In short, in a database this size, I wouldn't be surprised to find a lot
of errors with attribution, just like there are a lot of errors in other areas.
| | 4. I probably do have large images of many pieces for which previously there
were only small slots. However, in the case of the small minifig images in question
here, those large images were uploaded to the system at one time and rejected
in favor of another (usually existing) image for whatever reason. If they were
rejected before, why would I bother to go through the effort of finding all these
things and upload them to have them be rejected a second time?
|
It's hard for me to understand why an image of yours would get rejected,
but it does appear that in each of these cases, your small image (80 x 60) was
approved but your full size one wasn't.
These are all minifig images, so perhaps they didn't show the minifig built
exactly the right way, or didn't show front and back. The images could have
been rejected for any number of reasons.
However, a couple things have changed dramatically in the catalog since you uploaded
these images the first time. First, we have an additional image slot and we are
not afraid to use it. So if a good image comes in, we don’t have to completely
throw out someone else’s image to use yours.
The second thing that has changed is that high quality images with a white background
are greatly preferred over standard shots. Nice images were always appreciated,
but the emphasis was on correctness, not visual appeal.
So for example, the first minifig on the list currently has a large image showing
the neckpiece removed from the minifigure so as to show the printing on the torso.
In the past it was considered more desirable to be explicit about all details
of the figure, but now the emphasis is on a presentation of the minifigure that
will help sell it to today’s consumer.
So in short, we think that your previously rejected images would stand a good
chance of being accepted today. And when in comes to parts, you have many, many
80 x 60 images in the BL system that could easily be upgraded to a larger size.
| | I hope everyone understands I'm dispassionate about having my images included.
It's not an ego thing. I am concerned that I and other contributors are doing
what amounts to quite a bit of work, and there's a bug or flaw in the system
somewhere...or some bit of information hasn't been communicated appropriately...and
this problem persists, which may result in you having to go back to the contributors
and ask for a re-upload, and so on. And we're all chasing our tails. And
each other's tails.
In any event, I appreciate your efforts here. But you'll understand my reluctance
to comb through the back catalog of images I've created (or create new) and
upload them and so on without some assurance that they're going to be managed
efficiently and appropriately. I just see no sense in adding load to an existing
problem and I'd guess you don't want to be constantly manually fixing
all of it.
Thanks for the "fix" but I'm just not sure that the "why"...the reason for
things being out of whack...have been addressed as you shared no comment on that.
|
I understand the concern about mismanagement of images. But the site has actually
not lost anything or corrupted it. The attribution problems with certain minifig
images are all going to get ironed out anyway as we prepare to deprecate the
large image slot. If anything, we need to update the way credits are shown, and
make sure that contributors know exactly why an image is rejected.
|
|
| Author: | randyf | | Posted: | Jan 6, 2019 21:30 | | Subject: | Re: New Part Category | | Viewed: | 55 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | Today I added a new category: Wheel, Accessory.
I moved 31 parts from Wheel to the new category.
|
Very nice! That is a great addition to the catalog since so many wheel covers
are being made these days.
Cheers,
Randy
|
| Author: | StormChaser | | Posted: | Jan 6, 2019 20:23 | | Subject: | New Part Category | | Viewed: | 135 times | | Topic: | Catalog | | Status: | Open | |
|
| Today I added a new category: Wheel, Accessory.
I moved 31 parts from Wheel to the new category.
|
| Author: | WoutR | | Posted: | Jan 6, 2019 06:37 | | Subject: | Re: Part 35442 and 35449 name - flower or gear? | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, WoutR writes:
| | If you look at how these parts are used, then they are actually gear wheels.
Should the name not be "Plate, Modified [size] with [amount] Gear Tooth"?
|
Sure, why not. It was an easy fix. Some people in the future might not realize
they're gears and think they're flower petals, so now the titles include
both terms.
|
Thanks
|
|
| Author: | StormChaser | | Posted: | Jan 6, 2019 06:36 | | Subject: | Re: Part 35442 and 35449 name - flower or gear? | | Viewed: | 30 times | | Topic: | Catalog | |
|
| In Catalog, WoutR writes:
| | If you look at how these parts are used, then they are actually gear wheels.
Should the name not be "Plate, Modified [size] with [amount] Gear Tooth"?
|
Sure, why not. It was an easy fix. Some people in the future might not realize
they're gears and think they're flower petals, so now the titles include
both terms.
|
|
| Author: | WoutR | | Posted: | Jan 6, 2019 06:33 | | Subject: | Part 35442 and 35449 name - flower or gear? | | Viewed: | 74 times | | Topic: | Catalog | | Status: | Open | |
|
| Parts 35442 and 35449 were just added to the catalog. They are currently named
"Plate, Modified [size] with [amount] Flower Petals".
[p=35449]
If you look at how these parts are used, then they are actually gear wheels.
Should the name not be "Plate, Modified [size] with [amount] Gear Tooth"?
See https://youtu.be/o0I6SgQSMMQ?t=282
|
|
| Author: | axaday | | Posted: | Jan 5, 2019 23:02 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 29 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, axaday writes:
| | In Catalog, randyf writes:
| | All of these issues will be ironed out when they hit the inventory stage. Right
now they are just wrong images in the catalog.
Cheers,
Randy
|
They just hit the inventory stage. Pharah has a pretty extensive armor made
of pieces. What am I doing with that?
|
Pharah should be built as shown all the way to Step 6 on Page 7 of the first
instruction manual. Mercy should be built as shown all the way to Step 5 on Page
11 of the first instruction manual.
- Randy
|
Alright. Stop just short of hand weapons. I'll be on it in the morning.
|
|
| Author: | randyf | | Posted: | Jan 5, 2019 18:08 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, axaday writes:
| | In Catalog, randyf writes:
| | All of these issues will be ironed out when they hit the inventory stage. Right
now they are just wrong images in the catalog.
Cheers,
Randy
|
They just hit the inventory stage. Pharah has a pretty extensive armor made
of pieces. What am I doing with that?
|
Pharah should be built as shown all the way to Step 6 on Page 7 of the first
instruction manual. Mercy should be built as shown all the way to Step 5 on Page
11 of the first instruction manual.
- Randy
|
|
| Author: | tEoS | | Posted: | Jan 5, 2019 16:21 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 34 times | | Topic: | Catalog | |
|
| Based on many other catalog examples I would say that Mercy should have wings
in the assembly. I'm not sure if Pharah should just have the armor or
include the other pieces. I would like to find some comparable examples, though
all of this is up to an admin in the end.
| | Not to mention the angel should have her wings, right?
|
|
|
| Author: | axaday | | Posted: | Jan 5, 2019 15:58 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 25 times | | Topic: | Catalog | |
|
| In Catalog, axaday writes:
| | In Catalog, randyf writes:
| | All of these issues will be ironed out when they hit the inventory stage. Right
now they are just wrong images in the catalog.
Cheers,
Randy
|
They just hit the inventory stage. Pharah has a pretty extensive armor made
of pieces. What am I doing with that?
|
Not to mention the angel should have her wings, right?
|
|
| Author: | axaday | | Posted: | Jan 5, 2019 15:56 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 30 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | All of these issues will be ironed out when they hit the inventory stage. Right
now they are just wrong images in the catalog.
Cheers,
Randy
|
They just hit the inventory stage. Pharah has a pretty extensive armor made
of pieces. What am I doing with that?
|
| Author: | randyf | | Posted: | Jan 4, 2019 17:50 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 61 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | Thanks for the input.
I don't envy you the task of manually addressing every image in the catalog,
but suspect that's what it's going to take in the long run to remedy
this.
|
And now I see that Russell had already chimed in! D'oh! 
|
|
| Author: | randyf | | Posted: | Jan 4, 2019 17:49 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | Yup. The old system. Which for all its inadequacies functioned consistently and
as expected.
|
That it did. 
| | | | With the advent of the new system that was put in place a while ago, these attributions
at the bottom of the catalog pages are kind of meaningless,
|
If they're meaningless, why are they included? I know you don't know,
but rhetorically...?
|
My thoughts exactly.
| | Well, I'm not getting bent over the mechanics. Which I sort of understand.
I'm getting bent over the misrepresentation (which in this instance I see
as errors) and inconsistency.
|
They definitely *are* errors.
| | | | The current catalog page needs some reworking, but the only attributions that truly matter now are the ones listed on pages such as the following
|
I think maybe you could choose a...uh...more accurate/less dismissive phrase
than "the only attributions that
truly matter". Perhaps you mean "the only attributions that are truly accurate."
|
I am sorry, it wasn't meant to be dismissive. Your rewording is much more
in tune with what was meant.
| | All I'm trying to do is let somebody know that there's something gone
awry. And I appreciate your time and explanation.
|
I think Russell is aware that something has gone awry. I was just trying to provide
some insight into where the problems came from.
| | I'm looking for an explanation of what's gone wrong. Well. I'm hoping somebody
will look for an explanation of what's gone wrong and remedy it before it's
all FUBAR.
|
Hopefully Russell will be able to provide more information for you. Unfortunately,
my knowledge is limited to what I wrote above since I have never seen the admin
tools that are available to work with the images.
| | Fixing things is more labor intensive than not creating a problem in the first
place, at least in my experience.
|
I am a programmer, too, so I very much understand this.
| | And, if it's helpful in any way, feel free to remove any images I've
submitted to the catalog altogether.
|
I am sure that no one wants to do that. I think I speak for many when I say that
your contributions are amazing. Solving the problem is the end goal.
I wish I could have helped more, but I hope that you can get the help that you
are looking for.
Cheers,
Randy
|
|
| Author: | mfav | | Posted: | Jan 4, 2019 15:30 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 44 times | | Topic: | Catalog | |
|
| Thanks for the input.
I don't envy you the task of manually addressing every image in the catalog,
but suspect that's what it's going to take in the long run to remedy
this.
|
|
| Author: | mfav | | Posted: | Jan 4, 2019 15:17 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 50 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | The attribution at the bottom of the catalog pages is not dynamic. Those attributions
go to whoever supplied the old small image and old large image for the default
image slot in the old system.
In the old system, the old small image slot was able to be chosen among all of
the available colors in all small image slots (one for each color). Whichever
color small image was chosen to be the default one was who the small image got
attributed to on the catalog page.
Also in the old system, only one large image slot was available. The image stored
in this slot was who the large image got attributed to on the catalog page.
These two images could have two different contributors in the old system, which
is why there are two different contributors listed on many catalog pages.
|
Yup. The old system. Which for all its inadequacies functioned consistently and
as expected.
| | With the advent of the new system that was put in place a while ago, these attributions
at the bottom of the catalog pages are kind of meaningless,
|
If they're meaningless, why are they included? I know you don't know,
but rhetorically...?
| | and I would not put any weight in them since large images can be stored in each slot for every color
a part comes in and there is no longer a sole large image slot.
|
Well, I'm not getting bent over the mechanics. Which I sort of understand.
I'm getting bent over the misrepresentation (which in this instance I see
as errors) and inconsistency.
| | The current catalog page needs some reworking, but the only attributions that truly matter now are the ones listed on pages such as the following
|
I think maybe you could choose a...uh...more accurate/less dismissive phrase
than "the only attributions that
truly matter". Perhaps you mean "the only attributions that are truly accurate."
| | As long as you submit your images under the correct color slot, then you will get the correct attribution on those pages.
|
Well, okay, as far as color images go. If you say so. And relative to the catalog
page. Sort of. Sometimes.
1. There's an image of mine sw269 which was submitted properly as far as
I can tell (granted, no color tagged with figs) and it's sitting in your
small images gallery.
I've contributed at least 36 starwars minifigs to the catalog. I'm represented
by 23 currently in the small images gallery, 26 in the large gallery. Where are
the others?
If you search for sw049 in the top search box, my sw049 shows in the auto-search-dropdown
thingy. Click through on that and you get somebody else's sw049.
https://www.bricklink.com/v2/catalog/catalogitem.page?id=8272#T=S&O={"rpp":"500","iconly":0}
Click through from that page to item consists of 3 Parts
http://www.bricklink.com/catalogItemInv.asp?M=sw049
There the sw049 thumbnail is mine. Click the thumbnail, you get the other image.
sw049 isn't in either my small or large gallery. But it's clearly in
the system somewhere. Where'd it go?
2. There's not 1:1 correlation between the set of images shown here
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=30358&v=2
and the corresponding (sort of) images shown via the popup here
https://www.bricklink.com/v2/catalog/catalogitem.page?P=30358&idColor=1#T=C&C=2
Check out the tan image. On catalogColors.asp it's my image. On the part
popup on catalogitem.asp it's a render.
Click through the tan from this page
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=30358&v=2
( When I click through, half the time the picture block comes up blank, half
the time it comes up with the render. So, YMMV.)
The non-corresponding tan images suggests that images are being called from different
sources. If there are multiple sources it suggests that something on the DB level
is out of sync. Or something feeding data into the db is not quite right. Or
there was some issue somewhere in the past when things got "combined" where things
got a bit out of sorts.
All I'm trying to do is let somebody know that there's something gone
awry. And I appreciate your time and explanation. But I'm not looking for
an explanation of how it's "working" or how it's supposed to work. I'm
looking for an explanation of what's gone wrong. Well. I'm hoping somebody
will look for an explanation of what's gone wrong and remedy it before it's
all FUBAR. Which it will be, if my experience of the last couple weeks is any
indication. Fixing things is more labor intensive than not creating a problem
in the first place, at least in my experience.
And, if it's helpful in any way, feel free to remove any images I've
submitted to the catalog altogether.
|
|
| Author: | Admin_Russell | | Posted: | Jan 4, 2019 14:37 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 108 times | | Topic: | Catalog | |
|
|
BrickLink
ID CardAdmin_Russell
|
| Location: USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
|
Admin |
|
|
| BrickLink Administrator |
|
| Happy New Year to you as well! I'll answer these questions and those in the
other post directly. I appreciate the detective work you have put into this so
far.
In Catalog, mfav writes:
| | Happy New Year.
This image discrepancy thing does appear throughout the catalog.
It looks like any time there was a condition where the large image contributor
and the small image contributor were not the same, the large image contributor's
large image has slotted into the small image contributor's small image gallery.
At least one of mine is in Randy's gallery, a number of other people's
images are in Jen's gallery...it goes on.
|
The problem of attribution has been an issue for a long time. The site's
founder had attribution issues due to the credit system not being in place before
the site started accepting images. So we now have thousands of images credited
to "Admin" that really belong to someone else. Whenever people claim them we
tag the image with the username.
However, there are some new issues as well that stemmed from transferring large
banks of images to different slots for what is known broadly as the "image project",
the goal which was to unify the large and small image system to a single primary
image for each item (or color of each item) and use the additional image slot
for cases where more images were considered useful.
Like I said earlier, I wasn't here when most item types were transferred
over, so I don't know the exact procedure that was used. I only worked with
parts and I did them all manually.
But I have observed that for other item types like minifigs, the username was
not transfered when an image was copied to a new slot. So the old username is
paired with a "new" image. That is where the problem lies, and you are correct
- we need to do something about this.
| | I have a suspicion there's some other related gremlin somewhere in the works,
but I can't fathom it other than to note that sometimes the large images
are also somehow awry.
|
Regarding current manual functionality that admins use on a daily basis, we do
have some quirks backstage still that need to be ironed out. But none of these
involve attribution problems and overall it is very reliable when used in a specified
manner.
I can see where it appears to be credited to you, but actually it isn't.
See image 1. Image 2 shows the view from the admin page, and image 3 shows the
credits on the old colors page.
It depends where you navigate from. I personally do not like dynamic content
like this (I would rather it show the same view always, regardless of where someone
came from.) But this at some point was determined to be more helpful to new users,
so this is what we have.
Sometimes the large image space is empty depending on the device you are using.
I notice this when using my phone, and people have reported similar problems
with tablets. That is a bug and I'll write it up if I can reproduce it. I
suspect it is a cache issue.
I have added screenshots for this as well (see images 4 and 5). Medium Blue is
currently the default. Your red image is the Legacy image.
This is an excellent example of the catalog image system in flux. For this part
a decision needs to be made whether we consider it a "standard part" or an "early
variant". Because the variant differences can be seen so clearly from renders
and because the differences are great enough that this may not even qualify as
a "variant", I would consider this to be a borderline situation - hence why a
decision has not been made yet.
If we go with "standard part", then the preferred color images will be renders.
I would then trim the current images so they are optimized for showing in small
spaces (or accept replacement renders from someone who routinely makes these
sorts of adjustments) and I would move your image (red photo) to the additional
images section, which retains all credit and color info on the admin page. The
Legacy Image would then be replaced by the render in the default color to prepare
for the eventual deprecation of the Large/Legacy image slot.
If we go with "early variant" I would copy your image to the red color image
slot and select red as the default color. Then, as photos are submitted, they
would replace the renders that current occupy most color slots. The renders may
or may not be retained in the Additional Images section. When the Legacy Image
slot is retired, your red image in the Legacy slot would be removed (we never
actually delete things) but it would be retained in the color images section
at full size.
The Legacy image credit at the bottom of the page will be changed eventually
to Additional image credit, and additional image credits will also be shown on
other pages.
I have gone ahead and just changed the default color to Tan and copied your image
into the Tan slot. There is no reason to have the white image as default when
it is only 80 x 60 and has a non-white background.
You also have a Light Gray image for this part that is 80 x 60, but if you submitted
a larger size of that image, we would use that in place of the current default
color because it only shows one of the part.
In general, we want single item photos for the color slots to avoid any confusion
as to how many items the buyer will get. Multiple item / comparison images are
best suited as additional images where people can study them.
Another thing we could do is crop out one of the engines in your photo for the
color image and then use the full two-item image as an additional image.
But all of these adjustments take time and it's going to be a while before
we get all the images the way we want them. And a lot of it depends on the images
we receive in the meantime.
| | I thought the attribution dynamically changed on this page when you changed the
selected color of the piece from the popdown, but right now I can't find
where that's happening...
|
No, the credit information is static and a direct copy from the old catalog detail
page:
https://www.bricklink.com/catalogItem.asp?P=30358&useold=Y
| | but it may be effected with some pieces and not
others. In any event, the behavior on this page is inconsistent and seems to
have something to do with whether or not there's a "default" small image...which
is probably a misnomer. For example, as far as I can tell there are no "small"
images for
* | | 650 Hinge Coupling Nylon - Two Connected 2 x 2 Plates
Parts: Hinge |
Can't figure out how to back-trace any of these pictures to their creators...
...hmm...guessing that the large image attribution is for whatever image occupies
that second vertical thumbnail position there...
|
Yes, the second thumbnail position shows the Legacy/Large Image. Image 6 shows
what is behind the scenes for this part. You can't see the additional image
credit yet from any public page, but we of course want that to change.
| | Some of this might just be a UI problem where something isn't coded properly,
and with the 53588pb01 I doubt there is a gray version at all, just a dbg (this
was hashed about in the forum not too long ago).
|
We have left the other image in the Dark Gray slot until the inventories get
corrected. One way to accelerate action on an issue like this is to submit inventory
changes for the part - DG to DBG. Then it will be in a queue somewhere.
| | Anyway, I've spent about as much time as I care to looking at this issue.
All I really know is something or things has gone wrong somewhere, and I suggest
you want to sort it out before any more images get put into the system and possibly
mispositioned.
Also, I don't want to be wrongly credited for someone else's contribution.
That's just not right.
You and the StormChaser may want to consider holding off adding any new images
until you can sort out what's going on.
|
So there are two elements here. First, the general everyday work that is being
done to transform the system from the old version to the new version. This work
is going along fine and there is no reason to believe that ultimately credits
will accidentally be given to the wrong person.
The second issue is the large-scale imports/transfers/overwrites (whatever you
wish to call them) that were done between June of 2016 and May of 2017. These
were one-time actions and will not be repeated. So whatever went wrong with the
credit tranfer will not happen again. All that is left at this point is for someone
to go back and clean up the issue.
Now that this second issue has surfaced as a problem, I will need to add it to
the list of things to accomplish in the larger image project. I'll let you
know when I have fixed the images related to your username and hopefully we'll
see how to do a clean sweep to fix those for other users as well.
Again, thanks for your time spent finding what was wrong and writing it up. It
makes a big difference to have people actively working with us to solve stuff
that needs to be fixed.
|
|
|
| Author: | randyf | | Posted: | Jan 4, 2019 12:46 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 92 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | I thought the attribution dynamically changed on this page when you changed the
selected color of the piece from the popdown, but right now I can't find
where that's happening...but it may be effected with some pieces and not
others. In any event, the behavior on this page is inconsistent and seems to
have something to do with whether or not there's a "default" small image...which
is probably a misnomer. For example, as far as I can tell there are no "small"
images for
* | | 650 Hinge Coupling Nylon - Two Connected 2 x 2 Plates
Parts: Hinge |
|
The attribution at the bottom of the catalog pages is not dynamic. Those attributions
go to whoever supplied the old small image and old large image for the default
image slot in the old system.
In the old system, the old small image slot was able to be chosen among all of
the available colors in all small image slots (one for each color). Whichever
color small image was chosen to be the default one was who the small image got
attributed to on the catalog page.
Also in the old system, only one large image slot was available. The image stored
in this slot was who the large image got attributed to on the catalog page.
These two images could have two different contributors in the old system, which
is why there are two different contributors listed on many catalog pages.
With the advent of the new system that was put in place a while ago, these attributions
at the bottom of the catalog pages are kind of meaningless, and I would not put
any weight in them since large images can be stored in each slot for every color
a part comes in and there is no longer a sole large image slot.
The current catalog page needs some reworking, but the only attributions that
truly matter now are the ones listed on pages such as the following
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=53588pb01&v=2
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=41855&v=2
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=30358&v=2
As long as you submit your images under the correct color slot, then you will
get the correct attribution on those pages.
- Randy
|
|
| Author: | mfav | | Posted: | Jan 4, 2019 11:26 | | Subject: | Admin Russell, WTH images 2 | | Viewed: | 221 times | | Topic: | Catalog | | Status: | Open | |
|
| Happy New Year.
This image discrepancy thing does appear throughout the catalog.
It looks like any time there was a condition where the large image contributor
and the small image contributor were not the same, the large image contributor's
large image has slotted into the small image contributor's small image gallery.
At least one of mine is in Randy's gallery, a number of other people's
images are in Jen's gallery...it goes on.
I have a suspicion there's some other related gremlin somewhere in the works,
but I can't fathom it other than to note that sometimes the large images
are also somehow awry.
Example:
https://www.bricklink.com/v2/catalog/catalogitem.page?id=66490#T=C&C=10
The dbg image accessed via the popup is mine, and credited to me.
The gray image accessed via the popup is NOT mine, and credited to me...or at
least appears to be...or cannot be determined.
Sometimes
https://www.bricklink.com/v2/catalog/catalogitem.page
(with no color specified for the part) on entering the page, the large image
space is empty, other times it's populated with (I guess) a default image.
https://www.bricklink.com/v2/catalog/catalogitem.page?P=41855#T=C
I see a default (medium blue?) image, and at the bottom of the page I get a credit
for a large image. The red image here is mine, this blue one is not.
https://www.bricklink.com/v2/catalog/catalogitem.page?P=30358#T=C&C=2
This one defaults with a small white straked image (no color selected), I get
credit for the large image.
I thought the attribution dynamically changed on this page when you changed the
selected color of the piece from the popdown, but right now I can't find
where that's happening...but it may be effected with some pieces and not
others. In any event, the behavior on this page is inconsistent and seems to
have something to do with whether or not there's a "default" small image...which
is probably a misnomer. For example, as far as I can tell there are no "small"
images for
* | | 650 Hinge Coupling Nylon - Two Connected 2 x 2 Plates
Parts: Hinge |
Can't figure out how to back-trace any of these pictures to their creators...
...hmm...guessing that the large image attribution is for whatever image occupies
that second vertical thumbnail position there...
Some of this might just be a UI problem where something isn't coded properly,
and with the 53588pb01 I doubt there is a gray version at all, just a dbg (this
was hashed about in the forum not too long ago).
Anyway, I've spent about as much time as I care to looking at this issue.
All I really know is something or things has gone wrong somewhere, and I suggest
you want to sort it out before any more images get put into the system and possibly
mispositioned.
Also, I don't want to be wrongly credited for someone else's contribution.
That's just not right.
You and the StormChaser may want to consider holding off adding any new images
until you can sort out what's going on.
|
|
| Author: | yorbrick | | Posted: | Jan 4, 2019 08:18 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 45 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | | | I have to put some trust in members that items are submitted properly, especially
for new figures for which the assembly instructions are not always immediately
available. Sometimes that trust is repaid and sometimes it ain't. I have
a decent memory and submissions from the member who submitted these entries will
be checked carefully in the future.
It's a messier method in some ways, but I believe the benefits to members
outweigh making sure a catalog entry is absolutely perfect in every way before
approval. That's what change requests are for. This is not to say that
I don't check and occasionally reject things, of course. I'm just not
going to hold catalog entries forever, especially not desirable new items which
can easily be corrected. The inventory administrators, as Randy said, also sometimes
catch errors during the inventory process.
|
I know admins are probably against this, but I think people submitting the inventories
and pictures should actually have the set in front of them. Have a checkbox when
reserving them saying that the submitter has the set, and they have to tick it.
|
Nope, we are definitely not against this.
In fact, the Inventory Admins now require a new sealed set to be used for any
inventory that is less than one year old. This decision was made while Robert
and Marek were the Inventory Admins. That is why I mentioned that Marek and I
would have caught these errors during the inventory process even if Robert had
missed them at the catalog stage.
- Randy
|
Well that is good news. It shoudln't be about getting your name on most inventories
but getting it right first time, or as close as possible to first time. It should
be the same for minifigures and their pictures and inventories too.
|
|
| Author: | randyf | | Posted: | Jan 4, 2019 08:09 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | | | I have to put some trust in members that items are submitted properly, especially
for new figures for which the assembly instructions are not always immediately
available. Sometimes that trust is repaid and sometimes it ain't. I have
a decent memory and submissions from the member who submitted these entries will
be checked carefully in the future.
It's a messier method in some ways, but I believe the benefits to members
outweigh making sure a catalog entry is absolutely perfect in every way before
approval. That's what change requests are for. This is not to say that
I don't check and occasionally reject things, of course. I'm just not
going to hold catalog entries forever, especially not desirable new items which
can easily be corrected. The inventory administrators, as Randy said, also sometimes
catch errors during the inventory process.
|
I know admins are probably against this, but I think people submitting the inventories
and pictures should actually have the set in front of them. Have a checkbox when
reserving them saying that the submitter has the set, and they have to tick it.
|
Nope, we are definitely not against this.
In fact, the Inventory Admins now require a new sealed set to be used for any
inventory that is less than one year old. This decision was made while Robert
and Marek were the Inventory Admins. That is why I mentioned that Marek and I
would have caught these errors during the inventory process even if Robert had
missed them at the catalog stage.
- Randy
|
|
| Author: | yorbrick | | Posted: | Jan 4, 2019 04:33 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 30 times | | Topic: | Catalog | |
|
| | | I have to put some trust in members that items are submitted properly, especially
for new figures for which the assembly instructions are not always immediately
available. Sometimes that trust is repaid and sometimes it ain't. I have
a decent memory and submissions from the member who submitted these entries will
be checked carefully in the future.
It's a messier method in some ways, but I believe the benefits to members
outweigh making sure a catalog entry is absolutely perfect in every way before
approval. That's what change requests are for. This is not to say that
I don't check and occasionally reject things, of course. I'm just not
going to hold catalog entries forever, especially not desirable new items which
can easily be corrected. The inventory administrators, as Randy said, also sometimes
catch errors during the inventory process.
|
I know admins are probably against this, but I think people submitting the inventories
and pictures should actually have the set in front of them. Have a checkbox when
reserving them saying that the submitter has the set, and they have to tick it.
|
|
| Author: | StormChaser | | Posted: | Jan 3, 2019 23:22 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | Now I'm off to review the other figures this
member has recently submitted for potential additional errors.
|
Everything else is good.
Just to be clear, the fact that figures were incorrectly added to the catalog
was no one's fault other than my own. My job is to check things and I did
not check these things.
|
|
| Author: | StormChaser | | Posted: | Jan 3, 2019 23:06 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 41 times | | Topic: | Catalog | |
|
| In Catalog, tEoS writes:
| | More bad news. I just checked Lego's website for instructions and it appears
that Genji (dual-sword holder?) and Hanzo (quiver) are missing these neckgear
in their pictures here.
Also, Genji appears to have a piece that connects to his helmet.
|
Now I'm beginning to be embarrassed by my incompetence. I've fixed them:
I've also contacted anyone who has the four affected figures for sale and
alerted them of the issue. Now I'm off to review the other figures this
member has recently submitted for potential additional errors.
|
|
| Author: | tEoS | | Posted: | Jan 3, 2019 22:51 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 28 times | | Topic: | Catalog | |
|
| More bad news. I just checked Lego's website for instructions and it appears
that Genji (dual-sword holder?) and Hanzo (quiver) are missing these neckgear
in their pictures here.
Also, Genji appears to have a piece that connects to his helmet.
I don't have this set yet to confirm the contents. I'm going to run
to Walmart to see if they still have some.
In Catalog, StormChaser writes:
| | In Catalog, tEoS writes:
| | The picture for this fig is wrong.
|
I'm confused. The figure doesn't have a picture.
Only kidding. I removed the images just now. How and why did these images get
approved?
Well, the catalog (me) is trying to be more responsive than it has in the past.
That means more and better communication with members, quicker item approvals,
and no more long queues of pending items. One of the casualties of pumping out
catalog entries is that some get in which are wrong.
I have to put some trust in members that items are submitted properly, especially
for new figures for which the assembly instructions are not always immediately
available. Sometimes that trust is repaid and sometimes it ain't. I have
a decent memory and submissions from the member who submitted these entries will
be checked carefully in the future.
It's a messier method in some ways, but I believe the benefits to members
outweigh making sure a catalog entry is absolutely perfect in every way before
approval. That's what change requests are for. This is not to say that
I don't check and occasionally reject things, of course. I'm just not
going to hold catalog entries forever, especially not desirable new items which
can easily be corrected. The inventory administrators, as Randy said, also sometimes
catch errors during the inventory process.
Having said all that, it was my fault that I approved these images/figures when
they were incorrect and I apologize for the error. I believe the instructions
were already available when I approved those figures with those images and I
neglected to download and check the set instructions regarding the correct assembly.
As you've noticed, the images are gone now.
| | This one is up to the admins. The 1st assembly shown in instructions is the
standard w/ legs. I think this version is a good addition to the catalog, but
it may not fit the catalog policies.
|
There's kinda only one CA for now, and it's me. If the figure does not
match the assembly first shown in the set instructions, then it's off to
deleteland for that figure, which is where this figure has travelled.
Thank you for bringing these issues to my attention.
|
|
|
| Author: | StormChaser | | Posted: | Jan 3, 2019 22:32 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 50 times | | Topic: | Catalog | |
|
| In Catalog, tEoS writes:
| | The picture for this fig is wrong.
|
I'm confused. The figure doesn't have a picture.
Only kidding. I removed the images just now. How and why did these images get
approved?
Well, the catalog (me) is trying to be more responsive than it has in the past.
That means more and better communication with members, quicker item approvals,
and no more long queues of pending items. One of the casualties of pumping out
catalog entries is that some get in which are wrong.
I have to put some trust in members that items are submitted properly, especially
for new figures for which the assembly instructions are not always immediately
available. Sometimes that trust is repaid and sometimes it ain't. I have
a decent memory and submissions from the member who submitted these entries will
be checked carefully in the future.
It's a messier method in some ways, but I believe the benefits to members
outweigh making sure a catalog entry is absolutely perfect in every way before
approval. That's what change requests are for. This is not to say that
I don't check and occasionally reject things, of course. I'm just not
going to hold catalog entries forever, especially not desirable new items which
can easily be corrected. The inventory administrators, as Randy said, also sometimes
catch errors during the inventory process.
Having said all that, it was my fault that I approved these images/figures when
they were incorrect and I apologize for the error. I believe the instructions
were already available when I approved those figures with those images and I
neglected to download and check the set instructions regarding the correct assembly.
As you've noticed, the images are gone now.
| | This one is up to the admins. The 1st assembly shown in instructions is the
standard w/ legs. I think this version is a good addition to the catalog, but
it may not fit the catalog policies.
|
There's kinda only one CA for now, and it's me. If the figure does not
match the assembly first shown in the set instructions, then it's off to
deleteland for that figure, which is where this figure has travelled.
Thank you for bringing these issues to my attention.
|
|
| Author: | randyf | | Posted: | Jan 3, 2019 22:03 | | Subject: | Re: Overwatch Mercy & Pharah pictures wrong | | Viewed: | 33 times | | Topic: | Catalog | |
|
| All of these issues will be ironed out when they hit the inventory stage. Right
now they are just wrong images in the catalog.
Cheers,
Randy
In Catalog, tEoS writes:
| |
The picture for this fig is wrong. 1st her head sucks in comparison to what's
shown (but not really the point here).
2nd and most importantly, she needs at least the clear neck piece, if not the
full wing assembly
This fig has special shoulder armor that has some studs on the back for the other
pieces.
______
Not a picture issue:
[m=ow014]
This one is up to the admins. The 1st assembly shown in instructions is the
standard w/ legs. I think this version is a good addition to the catalog, but
it may not fit the catalog policies.
|
|
|
| Author: | tEoS | | Posted: | Jan 3, 2019 21:58 | | Subject: | Overwatch Mercy & Pharah pictures wrong | | Viewed: | 126 times | | Topic: | Catalog | | Status: | Open | |
|
|
The picture for this fig is wrong. 1st her head sucks in comparison to what's
shown (but not really the point here).
2nd and most importantly, she needs at least the clear neck piece, if not the
full wing assembly
This fig has special shoulder armor that has some studs on the back for the other
pieces.
______
Not a picture issue:
[m=ow014]
This one is up to the admins. The 1st assembly shown in instructions is the
standard w/ legs. I think this version is a good addition to the catalog, but
it may not fit the catalog policies.
|
|
| Author: | axaday | | Posted: | Jan 3, 2019 19:48 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, StormChaser writes:
| | In Catalog, randyf writes:
And I seem to remember a certain person telling me that it didn't matter
if parts appeared in the N/A color. 
|
(quickly looks one way, quickly looks the other, then turns and runs out the
door)
|
I'm just laying this out here because I'm not sure at all, but does anyone
think it was Randy?
|
|
| Author: | randyf | | Posted: | Jan 3, 2019 17:54 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, randyf writes:
And I seem to remember a certain person telling me that it didn't matter
if parts appeared in the N/A color.
|
(quickly looks one way, quickly looks the other, then turns and runs out the
door)
|
| Author: | StormChaser | | Posted: | Jan 3, 2019 17:39 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
And I seem to remember a certain person telling me that it didn't matter
if parts appeared in the N/A color.
|
| Author: | randyf | | Posted: | Jan 3, 2019 17:29 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, qwertyboy writes:
| | In Catalog, yoavheskia writes:
| | i counted only 51 known colors, not 52 as mentioned in catalog statisics.
|
This might be because of the "(not applicable)" color that is shown when you
look at the "item appears in:" - "39 parts" for item [p=4073c01]
That would be "color" #52.
Niek.
|
Bingo!
|
|
| Author: | qwertyboy | | Posted: | Jan 3, 2019 17:26 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, yoavheskia writes:
| | i counted only 51 known colors, not 52 as mentioned in catalog statisics.
|
This might be because of the "(not applicable)" color that is shown when you
look at the "item appears in:" - "39 parts" for item [p=4073c01]
That would be "color" #52.
Niek.
|
|
| Author: | MidwestBrick | | Posted: | Jan 3, 2019 17:12 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 26 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, yoavheskia writes:
| | i counted only 51 known colors, not 52 as mentioned in catalog statisics.
|
That is odd. I cannot explain it. I thought the statistics were real-time data.
Even if not, I don't see any recent changes which could have caused this
discrepancy.
|
Must have counted itself as one. Silly catalog, you are not a color.
|
|
| Author: | StormChaser | | Posted: | Jan 3, 2019 16:53 | | Subject: | Re: part 4073: catalog statisics mistake | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, yoavheskia writes:
| | i counted only 51 known colors, not 52 as mentioned in catalog statisics.
|
That is odd. I cannot explain it. I thought the statistics were real-time data.
Even if not, I don't see any recent changes which could have caused this
discrepancy.
|
| Author: | yoavheskia | | Posted: | Jan 3, 2019 16:46 | | Subject: | part 4073: catalog statisics mistake | | Viewed: | 91 times | | Topic: | Catalog | | Status: | Open | |
|
| | i counted only 51 known colors, not 52 as mentioned in catalog statisics. |
|
| Author: | randyf | | Posted: | Jan 3, 2019 15:18 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
OK, but doesn't that hold for many part variations for older sets? These
parts look identical apart from the code number, don't they? Whereas there
are many variations of the good old 1x4 or 2x4 brick that don't get entries
or notes. There is no mention at all for the 1x4 brick, for example, that the
underneaths may have solid or holed rods, or cross supports, and so on.
|
So have the notes added to the parts you would like more information on just
like I had that note added to the boat stud back in the day. Easy peasy.
The item number 93791 on some boat studs is *very* specific to a certain time
and place of manufacture unlike the overwhelming majority of parts, and I thought
the information was beneficial to add before it got lost to the sands of time.
Getting rid of good knowledge for the sake of getting rid of it is unnecessary.
In fact, my general argument for BrickLink as a whole was always to get as much
information as possible into the system from the huge amount of LEGO knowledge
that frequents this site regularly.
Cheers,
Randy
|
So wouldn't the information about which LEGO-issued number boat stud be better
placed in the notes for those specific sets? After all, if I look at those sets,
there is nothing in the set notes to tell me that and there is nothing in the
inventory to tell me that. It is only if you look in the notes for each individual
part that this would ever be highlighted.
|
Are you one of those people who love to ask questions about everything but never
take any action? Because it sure seems that way.
I put the information where I thought it should go. That's it. Nothing more,
nothing less. I didn't analyze every situation that would come up for every
person who would like to maybe find that information.
If you think it should go somewhere else, then make a request to have it changed.
|
|
| Author: | mfav | | Posted: | Jan 3, 2019 12:57 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 78 times | | Topic: | Catalog | |
|
| Well, now I can understand why the StormChaser is confused.
If the large image slot is going away, and the large images are going to then
slot into what now is the small slot...
...and I get keeping the small slot because the small slot had ALL colors of
a piece where the large slot typically had one "representative" image per piece
and not per color...
...then I think the solution would be to leave the small images as they were
(as those were the large images slotted down into the small slot) and change
the credit to the appropriate contributor.
If I understand the plan, which I may not, and apparently is also not clear to
more than just me, the plan is to replace all the small images with large images
as they become available. You're keeping the small slot because that slot
is already prepped to contain multiple colors of a piece where the large slot
is not...and you have small images of more pieces than you have large images.
I imagine that you'd lose ~70% of the images if you kept the large set and
abandoned the small set...because you don't have all colors in the large
set.
Right? So I can see the logic of that strategy.
Still.
That leaves me with these questions:
1. Why plug my small images back into the small slot? Why not leave the large-image-put-into-the-small-slot
(as this is the goal) and change the contributor? Seems like you're going
to have to go back and do that at some point.
2. All the legs images in question are recent contributions, and while they may
have slotted into the small slot correctly, that doesn't answer why the large
images are getting mis-attributed. And will the mis-attribution continue?
3. Are there other images in the system that are similarly mis-attributed?
4. I probably do have large images of many pieces for which previously there
were only small slots. However, in the case of the small minifig images in question
here, those large images were uploaded to the system at one time and rejected
in favor of another (usually existing) image for whatever reason. If they were
rejected before, why would I bother to go through the effort of finding all these
things and upload them to have them be rejected a second time?
I hope everyone understands I'm dispassionate about having my images included.
It's not an ego thing. I am concerned that I and other contributors are doing
what amounts to quite a bit of work, and there's a bug or flaw in the system
somewhere...or some bit of information hasn't been communicated appropriately...and
this problem persists, which may result in you having to go back to the contributors
and ask for a re-upload, and so on. And we're all chasing our tails. And
each other's tails.
In any event, I appreciate your efforts here. But you'll understand my reluctance
to comb through the back catalog of images I've created (or create new) and
upload them and so on without some assurance that they're going to be managed
efficiently and appropriately. I just see no sense in adding load to an existing
problem and I'd guess you don't want to be constantly manually fixing
all of it.
Thanks for the "fix" but I'm just not sure that the "why"...the reason for
things being out of whack...have been addressed as you shared no comment on that.
|
|
| Author: | yorbrick | | Posted: | Jan 3, 2019 05:13 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 41 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
OK, but doesn't that hold for many part variations for older sets? These
parts look identical apart from the code number, don't they? Whereas there
are many variations of the good old 1x4 or 2x4 brick that don't get entries
or notes. There is no mention at all for the 1x4 brick, for example, that the
underneaths may have solid or holed rods, or cross supports, and so on.
|
So have the notes added to the parts you would like more information on just
like I had that note added to the boat stud back in the day. Easy peasy.
The item number 93791 on some boat studs is *very* specific to a certain time
and place of manufacture unlike the overwhelming majority of parts, and I thought
the information was beneficial to add before it got lost to the sands of time.
Getting rid of good knowledge for the sake of getting rid of it is unnecessary.
In fact, my general argument for BrickLink as a whole was always to get as much
information as possible into the system from the huge amount of LEGO knowledge
that frequents this site regularly.
Cheers,
Randy
|
So wouldn't the information about which LEGO-issued number boat stud be better
placed in the notes for those specific sets? After all, if I look at those sets,
there is nothing in the set notes to tell me that and there is nothing in the
inventory to tell me that. It is only if you look in the notes for each individual
part that this would ever be highlighted.
|
|
| Author: | Admin_Russell | | Posted: | Jan 3, 2019 00:07 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 136 times | | Topic: | Catalog | |
|
|
BrickLink
ID CardAdmin_Russell
|
| Location: USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
|
Admin |
|
|
| BrickLink Administrator |
|
| In Catalog, mfav writes:
| | I'm noticing my "large" images for these items are showing up as being credited
to other contributors.
Kevin1990
|
[p=970c00pb099]
[p=970c00pb075]
[p=970c00pb195]
[p=970c00pb337]
(red)
| |
And I'm credited for these "small" images which aren't mine...and no
idea whose they are.
|
[m=cty057]
[m=sw016]
[m=sw049]
| |
(I thought the whole "small image" thing was kaput some time last year...no?)
If this is human error, that's one thing. If there are systemic issues or
database corruption or something else going on, then it probably should be looked
into before it gets worse.
|
Thanks for reporting this. We want to hear from people when things don't
seem right!
Regarding the first batch (minifigure legs), all of your images were indeed stored
in the "small image" slot, which is good, because the large image slot will be
going away. But I just went through these and added your images to the large
image slot for the time being so people will see them everywhere.
There is no problem with the system with this first batch. This is a simple question
of temporary assignment. I had planned to completely hide the large image credit
at this point, but as long as it's still around, we'll try to keep both
slots updated.
The second batch is more troubling. Before I took the reigns of the image project
in May of 2017, there were several attempts to solve some image issues an "easier"
way (i.e. not through the regular upload forms). This resulted in some unexpected
and often unfortunate situations, and it is a prime example of why I am very
reluctant to recommend ANY automatic processes when handling BrickLink's
data.
The images you see (all minifigures) are indeed not yours, but I believe your
username was attached to that slot because at one time you did have an image
there, probably a replacement image for the image now present.
I don't know if you keep files of your submitted images. I know many users
don't, but I still recommend it in case there is an issue like this. But
if you do have such a record, please check if you have images for any minifigures
in the list you provided.
If you do have them, please upload and we will correct the situation through
the regular forms. If not, I will try to find the images on an older version
of the site and I'll take care of it manually.
I'll check all these entries again, but I believe I have taken care of all
username issues you have presented today.
|
|
| Author: | StormChaser | | Posted: | Jan 2, 2019 17:28 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 58 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | Just thinking
it's smarter to fix the problem now before another gazillion images get posted
and end up in the wrong slot and then need to be "fixed".
|
Agreed and thank you for bringing it up. It could be human error since I approved
some of the images you mention. I'm sure Russell will shed some light on
the issue.
|
|
| Author: | mfav | | Posted: | Jan 2, 2019 17:23 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 70 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | It's all rather confusing, even to me, but I don't believe it is the
result of either human error or database corruption.
|
It has to be one or the other or both. It may occur in the underlying programming
which does whatever it does when an "old" image gets replaced (or bumped, or
set to primary, or whatever you call it) with a "new" image.
If my "new" "large" image replaced otherperson's "large" image...used to
be I'd get credit for "large" image. Now, in some circumstances which I cannot
define, my "new" image ends up being credited to the previous(?) large image
uploader. Or something.
There's not supposed to be either "large" or "small" image any more. Now
there's just "image" and where there used to be "small" and "large" there
is now "multiple"....at least that's how I understood the Great Image Declaration
from Russell some time back.
If my images are showing up in somebody else's register, and somebody else's
images are showing up in someotherbodyelse's register...well...that's
database corruption.
Maybe it's just programming, but something somewhere is awry. Just thinking
it's smarter to fix the problem now before another gazillion images get posted
and end up in the wrong slot and then need to be "fixed".
|
|
| Author: | StormChaser | | Posted: | Jan 2, 2019 16:49 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 81 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | you are credited with the large image.
|
| | and the small image is credited to hazelsden.
|
Oops. Other way around. Confusing, as I said, even to me.
|
|
| Author: | StormChaser | | Posted: | Jan 2, 2019 16:45 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 96 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | I'm noticing my "large" images for these items are showing up as being credited
to other contributors.
|
Russell would indeed be the person to answer this, but in many cases it comes
down to the way the system is designed. On this, for example:
The legacy image is from hazelsden. The color image is from you. The color
image is shown as the primary image, which is why you are credited with the large
image. The legacy image also exists, which is why it is shown as an additional
image and the small image is credited to hazelsden.
It's all rather confusing, even to me, but I don't believe it is the
result of either human error or database corruption.
| | And I'm credited for these "small" images which aren't mine...and no
idea whose they are.
|
Those I cannot explain.
|
|
| Author: | mfav | | Posted: | Jan 2, 2019 16:33 | | Subject: | Admin Russell, what's with the images? | | Viewed: | 252 times | | Topic: | Catalog | | Status: | Open | |
|
| I'm noticing my "large" images for these items are showing up as being credited
to other contributors.
Kevin1990
- 970c00pb099
- 970c34pb01
swrbricks
- 970c10pb01
- 970c09pb01
- 970c11pb04
jennnifer
- 970c69pb01
- 970c00pb075
- 970c00pb195
Nikilyn
- 970c00pb337
hazelsden
- 970c86pb02
www_mybricks_de
- 970c00 (red)
And I'm credited for these "small" images which aren't mine...and no
idea whose they are.
air023
atl017
gen052
gen053
stu002
cty057
sw016
aqu011
lea005
sw049
twn029
pln100
pln003
pln050
pln057
pln058
pm012
soc034
(I thought the whole "small image" thing was kaput some time last year...no?)
If this is human error, that's one thing. If there are systemic issues or
database corruption or something else going on, then it probably should be looked
into before it gets worse.
|
|
| Author: | randyf | | Posted: | Jan 2, 2019 15:21 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In Catalog, Dino1 writes:
| | In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
And why do you and others add "alternate" Numbers to parts, without naming the
sets?
Werner
|
Because most of them are in my opinion "generic" and do not have any significance
for me or my collection. This boat stud has a lot of significance for my Ninjago
collection, so I asked for the note to be added. If others want notes added to
other parts that are important to them, then they can request them just like
I did. No one is stopping you or anyone else from doing that. In the end though,
it is at the discretion of the Catalog Admins whether any notes get added.
Cheers,
Randy
|
|
| Author: | randyf | | Posted: | Jan 2, 2019 15:09 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 32 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
OK, but doesn't that hold for many part variations for older sets? These
parts look identical apart from the code number, don't they? Whereas there
are many variations of the good old 1x4 or 2x4 brick that don't get entries
or notes. There is no mention at all for the 1x4 brick, for example, that the
underneaths may have solid or holed rods, or cross supports, and so on.
|
So have the notes added to the parts you would like more information on just
like I had that note added to the boat stud back in the day. Easy peasy.
The item number 93791 on some boat studs is *very* specific to a certain time
and place of manufacture unlike the overwhelming majority of parts, and I thought
the information was beneficial to add before it got lost to the sands of time.
Getting rid of good knowledge for the sake of getting rid of it is unnecessary.
In fact, my general argument for BrickLink as a whole was always to get as much
information as possible into the system from the huge amount of LEGO knowledge
that frequents this site regularly.
Cheers,
Randy
|
|
| Author: | Dino | | Posted: | Jan 2, 2019 15:04 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
And why do you and others add "alternate" Numbers to parts, without naming the
sets?
Werner
|
|
| Author: | yorbrick | | Posted: | Jan 2, 2019 14:52 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
OK, but doesn't that hold for many part variations for older sets? These
parts look identical apart from the code number, don't they? Whereas there
are many variations of the good old 1x4 or 2x4 brick that don't get entries
or notes. There is no mention at all for the 1x4 brick, for example, that the
underneaths may have solid or holed rods, or cross supports, and so on.
|
|
| Author: | randyf | | Posted: | Jan 2, 2019 14:30 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
It does not seem pointless to me. If you want to complete a Ninjago spinner set
from the original era of Ninjago with all original parts, you will want the boat
stud that was made in China with item number 93791 and not item number 2654.
Cheers,
Randy
|
| Author: | yorbrick | | Posted: | Jan 2, 2019 13:12 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 52 times | | Topic: | Catalog | |
|
| This one seems fairly pointless:
"93791 found in Ninjago sets from 2011 in Black, Red and Dark Bluish Gray"
|
|
| Author: | grimsbricksuk | | Posted: | Jan 2, 2019 12:51 | | Subject: | Re: Issue with New Minifig sw988 | | Viewed: | 32 times | | Topic: | Catalog | |
|
| Just seen this post...
The names of the minifigs were only my proposed suggestions & can be changed
by anyone at anytime following approval. I did not want to reference sw988 as
'Angry Clone' or 'Mad Face' as you suggest because I wanted
to better identify the main difference between sw988 & sw986
Also, these are three separate Star Wars characters, therefore they justified
their own 'sw' number in my opinion, rather than have a/b/c variants.
Finally, I was unable to upload images which also showed the faces as I'm
still learning how to do that, any help there would be appreciated.
In Catalog, LordInTheNorth writes:
| | This minifig is listed wrong in the catalog. The out side parts of the 3 minifigs
in set 75226 are all the same but one has a belt ... and other differences are
...
sw988 - a - normal storm trooper head (male) with belt part ... like in batman
sets (but black)
sw988 - b - sunken eyes no belt. (outside same as others minus the belt)
sw988 - c - mad face no belt. (outside same as others minus the belt)
Not sure what needs to happen but ... that minifig should be changed.
|
|
|
| Author: | StormChaser | | Posted: | Jan 1, 2019 21:07 | | Subject: | Re: Sixth Catalog Project Underway | | Viewed: | 51 times | | Topic: | Catalog | |
|
| An anonymous person would like the following information added for review:
The additional note for
[s=yoda-1]
is too bloated since most of that information is included in the help page for
the "Cannot be Inventoried" flag. I suggest simplifying it to just "This set
is a glued model." or getting rid of the note entirely and adding "(Glued Model)"
to the set name.
--------------------------------------------------------------------------------
The additional note for
is unnecessary since the set name includes "polybag" and the set relationships
includes the other set. I suggest removing the note entirely.
|
|
| Author: | WoutR | | Posted: | Jan 1, 2019 17:53 | | Subject: | Re: 2 versions of dino tail end #40379 | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In Catalog, WoutR writes:
| | In Catalog, StormChaser writes:
| | In Catalog, tEoS writes:
| | There are two versions of this part where the small hole by the base varies
in location, mirrored left or right side.
|
If you'll post a comparison picture, then I'll add an additional note
to the part mentioning the difference and also add this part to our list of known
variants.
|
|
I don't know what happened here, but the website is responding very slow
and all my text is gone...
The different versions could simply be different cavity positions in the mold.
If those are evenly distributed in the mold, then we could expert to find approximately
equal amounts in sets.
|
|
| Author: | StormChaser | | Posted: | Jan 1, 2019 14:50 | | Subject: | Re: 2 versions of dino tail end #40379 | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, tEoS writes:
| | There are two versions of this part where the small hole by the base varies
in location, mirrored left or right side.
|
If you'll post a comparison picture, then I'll add an additional note
to the part mentioning the difference and also add this part to our list of known
variants.
|
|
| Author: | StormChaser | | Posted: | Jan 1, 2019 14:47 | | Subject: | Re: Issue with New Minifig sw988 | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, LordInTheNorth writes:
| | So open mouth is ... mad face?
Weird ... ok then.
|
I did not title this figure. The person who titled the figure was a person who
had the figure in hand to see what the face actually looks like. Titles can
easily be changed and if you feel that the current title does not accurately
describe the figure, then please request a title change using this form:
https://www.bricklink.com/catalogReq.asp
|
|
| Author: | tEoS | | Posted: | Jan 1, 2019 14:43 | | Subject: | 2 versions of dino tail end #40379 | | Viewed: | 70 times | | Topic: | Catalog | | Status: | Open | |
|
|
There are two versions of this part where the small hole by the base varies
in location, mirrored left or right side.
This can be seen in the new carousel where it seems Lego tried to include 24/24
(I got 23/25) of each type, so that the holes wouldn't be visible.
|
| Author: | LordInTheNorth | | Posted: | Jan 1, 2019 14:38 | | Subject: | Re: Issue with New Minifig sw988 | | Viewed: | 34 times | | Topic: | Catalog | |
|
| So open mouth is ... mad face?
Weird ... ok then.
|
| Author: | StormChaser | | Posted: | Jan 1, 2019 14:30 | | Subject: | Re: Issue with New Minifig sw988 | | Viewed: | 47 times | | Topic: | Catalog | |
|
| In Catalog, LordInTheNorth writes:
| | Not sure what needs to happen but ... that minifig should be changed.
|
These are pending and have been for some time:
[M=sw986]
[M=sw987]
[M=sw988]
What needs to happen is that someone needs to upload pictures so the figures
can be approved.
|
|
| Author: | LordInTheNorth | | Posted: | Jan 1, 2019 14:24 | | Subject: | Issue with New Minifig sw988 | | Viewed: | 105 times | | Topic: | Catalog | | Status: | Open | |
|
| This minifig is listed wrong in the catalog. The out side parts of the 3 minifigs
in set 75226 are all the same but one has a belt ... and other differences are
...
sw988 - a - normal storm trooper head (male) with belt part ... like in batman
sets (but black)
sw988 - b - sunken eyes no belt. (outside same as others minus the belt)
sw988 - c - mad face no belt. (outside same as others minus the belt)
Not sure what needs to happen but ... that minifig should be changed.
|
|
| Author: | FreeStorm | | Posted: | Dec 31, 2018 23:00 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 31 times | | Topic: | Catalog | |
|
| In Catalog, Redhawk_Kevin writes:
Thank you for that great link
I definitively have bbw083 version
Now I can take pictures/weight/size of my parts and add it to the catalog for
part bbw083
|
|
|
| Author: | FreeStorm | | Posted: | Dec 31, 2018 22:14 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 22 times | | Topic: | Catalog | |
|
| In Catalog, Redhawk_Kevin writes:
| | I've done a lot of work with the watches recently. The OP is both correct
and incorrect.
Correct in the sense that bbw001 does have wrong dimensions currently. There
may have been early variant of this part since I only have watches from 2007
until current, but the links that I have are 1.8cm in width.
Incorrect in the sense that the watch that FreeStorm has does not actually contain
bbw001 links. Instead that watch contains the new bbw083 link that was added
to the catalog.
[g=bbw083]
-Kevin
In Catalog, StormChaser writes:
| | In Catalog, FreeStorm writes:
| | Is it a sufficient prove to update the catalog with "my" size and weight?
|
If we're talking about proof, then the only proof would be to measure and
weigh the actual item from 2013. Measuring/weighing your item and then changing
the dimensions/weight of another item which you believe to be the same based
on a poor-quality catalog photo is not proof, but only conjecture.
However, you are welcome to submit change requests if you'd like and I'll
consider them. Perhaps someone reading this can confirm these dimensions for
the existing catalog entry?
|
|
Can you explain me the difference (I don't see it in the pictures)
|
|
| Author: | FreeStorm | | Posted: | Dec 31, 2018 21:54 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 22 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, FreeStorm writes:
| | Is it a sufficient prove to update the catalog with "my" size and weight?
|
If we're talking about proof, then the only proof would be to measure and
weigh the actual item from 2013. Measuring/weighing your item and then changing
the dimensions/weight of another item which you believe to be the same based
on a poor-quality catalog photo is not proof, but only conjecture.
However, you are welcome to submit change requests if you'd like and I'll
consider them. Perhaps someone reading this can confirm these dimensions for
the existing catalog entry?
|
I know that a picture is not a proof, but we are speaking of 4.25mm (22.5mm vs
18mm) that is ~1/4 of the size of the parts. Even with a bad picture, we can
compare it.
You can compare my picture with 8 other picture (with studs) of this part on
the catalog.
It's okay, I'll wait for someone else to update these parts.
|
|
| Author: | Redhawk_Kevin | | Posted: | Dec 31, 2018 21:38 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 28 times | | Topic: | Catalog | |
|
| To add to this, I believe the current dimensions are in studs and not in cm.
- Kevin
| | In Catalog, StormChaser writes:
| | In Catalog, FreeStorm writes:
| | Is it a sufficient prove to update the catalog with "my" size and weight?
|
If we're talking about proof, then the only proof would be to measure and
weigh the actual item from 2013. Measuring/weighing your item and then changing
the dimensions/weight of another item which you believe to be the same based
on a poor-quality catalog photo is not proof, but only conjecture.
However, you are welcome to submit change requests if you'd like and I'll
consider them. Perhaps someone reading this can confirm these dimensions for
the existing catalog entry?
|
|
|
|
| Author: | Redhawk_Kevin | | Posted: | Dec 31, 2018 21:34 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 26 times | | Topic: | Catalog | |
|
| I've done a lot of work with the watches recently. The OP is both correct
and incorrect.
Correct in the sense that bbw001 does have wrong dimensions currently. There
may have been early variant of this part since I only have watches from 2007
until current, but the links that I have are 1.8cm in width.
Incorrect in the sense that the watch that FreeStorm has does not actually contain
bbw001 links. Instead that watch contains the new bbw083 link that was added
to the catalog.
[g=bbw083]
-Kevin
In Catalog, StormChaser writes:
| | In Catalog, FreeStorm writes:
| | Is it a sufficient prove to update the catalog with "my" size and weight?
|
If we're talking about proof, then the only proof would be to measure and
weigh the actual item from 2013. Measuring/weighing your item and then changing
the dimensions/weight of another item which you believe to be the same based
on a poor-quality catalog photo is not proof, but only conjecture.
However, you are welcome to submit change requests if you'd like and I'll
consider them. Perhaps someone reading this can confirm these dimensions for
the existing catalog entry?
|
|
|
| Author: | StormChaser | | Posted: | Dec 31, 2018 21:14 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 19 times | | Topic: | Catalog | |
|
| In Catalog, FreeStorm writes:
| | Is it a sufficient prove to update the catalog with "my" size and weight?
|
If we're talking about proof, then the only proof would be to measure and
weigh the actual item from 2013. Measuring/weighing your item and then changing
the dimensions/weight of another item which you believe to be the same based
on a poor-quality catalog photo is not proof, but only conjecture.
However, you are welcome to submit change requests if you'd like and I'll
consider them. Perhaps someone reading this can confirm these dimensions for
the existing catalog entry?
|
|
| Author: | FreeStorm | | Posted: | Dec 31, 2018 21:04 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 18 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, FreeStorm writes:
| | my parts for
the Watch are not the same weight and size as catalog items.
|
| | it look like my Watch from 2017 is smaller than watch from 2013
|
I've changed the topic of your post from Catalog Requests to Catalog. The
requests topic is for when you're making a specific request that something
be changed which cannot be changed through existing forms. You do not appear
to making any requests, but only asking for an opinion.
My opinion is that one of two possibilities could be true:
1. Your watch and all its components are smaller. This seems unlikely, but
still possible. If true, all parts would need to be added separately.
2. The current dimensions and weights for the existing parts are incorrect.
If true, correct dimensions should be added.
The only way to know for sure what the reality is would be to have both items
in hand and physically compare them. If you're able to pick up the 2013
watch cheaply, then this is what I'd recommend before coming to any conclusions.
|
Thanks for you reply,
While looking at bbw001 pictures
[g=bbw001]
I found that the correct width should be 1.8cm not 2.25cm
The picture with the ruler is from my Watch, the picture with the tan parts are
from the catalog
You can see that my parts and the catalog parts are the same size.
Is it a sufficient prove to update the catalog with "my" size and weight?
|
|
|
| Author: | StormChaser | | Posted: | Dec 31, 2018 15:35 | | Subject: | Re: Different size for Watches parts bbw002 | | Viewed: | 28 times | | Topic: | Catalog | |
|
| In Catalog, FreeStorm writes:
| | my parts for
the Watch are not the same weight and size as catalog items.
|
| | it look like my Watch from 2017 is smaller than watch from 2013
|
I've changed the topic of your post from Catalog Requests to Catalog. The
requests topic is for when you're making a specific request that something
be changed which cannot be changed through existing forms. You do not appear
to making any requests, but only asking for an opinion.
My opinion is that one of two possibilities could be true:
1. Your watch and all its components are smaller. This seems unlikely, but
still possible. If true, all parts would need to be added separately.
2. The current dimensions and weights for the existing parts are incorrect.
If true, correct dimensions should be added.
The only way to know for sure what the reality is would be to have both items
in hand and physically compare them. If you're able to pick up the 2013
watch cheaply, then this is what I'd recommend before coming to any conclusions.
|
|
| Author: | FreeStorm | | Posted: | Dec 31, 2018 13:11 | | Subject: | Different size for Watches parts bbw002 | | Viewed: | 64 times | | Topic: | Catalog | | Status: | Open | |
|
| Hello,
I own the 2017 version of 9005008 (in 24-Hour format)
While I'm looking for size and weight of parts it look that my parts for
the Watch are not the same weight and size as catalog items.
For example:
bbw001
Mine: 1.8 x 1.0 x 0.41 for 0.2g
Catalog: 2.25 x 1.25 for 0.33g
bbw002:
Mine: 1.8 x 1.7 x 0.4 for 0.3g
Catalog: 2.25 x 2.25 cm for 0.51g
it look like my Watch from 2017 is smaller than watch from 2013
I'm pretty sure for the size of my parts, I'm using an electronic caliper
And a balance accurate to 0.1 g
What do you think?
|
|
| Author: | StormChaser | | Posted: | Dec 31, 2018 02:25 | | Subject: | Re: 93273pb089 deletion | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, phyllisw8 writes:
| | I just added a more complete and correct entry of this part as 93273pb090. 93273pb089
is currently pending approval and should either be deleted or my submitted information
from 93273pb090 be transferred to the entry.
|
I've changed your post to the Catalog topic since the Catalog Requests topic
is for me to change something in the catalog. This pending part is not yet in
the catalog.
As for correcting it, you're definitely right - it does need plenty of correcting
before it can be approved. I will get to it eventually.
Since the other member submitted the catalog entry first, I'll probably approve
that submission after correction and remove your pending submission.
|
|
| Author: | phyllisw8 | | Posted: | Dec 30, 2018 23:27 | | Subject: | 93273pb089 deletion | | Viewed: | 70 times | | Topic: | Catalog | | Status: | Open | |
|
| I just added a more complete and correct entry of this part as 93273pb090. 93273pb089
is currently pending approval and should either be deleted or my submitted information
from 93273pb090 be transferred to the entry.
|
|
| Author: | waltzking | | Posted: | Dec 28, 2018 02:22 | | Subject: | Re: Please approve 30529-1 (In Hand) | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, waltzking writes:
| | Have this item in hand and would like to see it approved soon.
|
We have no image for this item and it will not be approved without an image.
Please upload an image.
|
Photo has been submitted. Will update weight and such once it is approved.
Jonathan
|
| Author: | bricksahead | | Posted: | Dec 27, 2018 12:25 | | Subject: | Re: Duplo Sheep Expert? | | Viewed: | 31 times | | Topic: | Catalog | |
|
| I've both types of sheep. They do look like they're made from the same
mold.
In Catalog, axaday writes:
| | Are [p=dupsheepnew] and the same mold? It looks like it as far
as I can tell.
|
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
Denmark
United Kingdom, England
Netherlands, Gelderland
)
)
)
)
)
)
Canada, Alberta
Israel, Mehoz Tel Aviv
Luxembourg
Switzerland, Vaud
)
)
