| |
What are the physical colour parts such as
this one for?
Wouldn’t it be more disk-space saving to rather have a list of coloured part
numbers? I have my hands on quite a lot of them through building instructions,
and I think that if one made a physical colour part of each one of them the PT
would be soon cluttered up by them.
|
|
| |
In lugnet.cad, Santeri Piippo wrote:
| |
What are the physical colour parts such as
this one for?
Wouldn’t it be more disk-space saving to rather have a list of coloured part
numbers? I have my hands on quite a lot of them through building
instructions, and I think that if one made a physical colour part of each one
of them the PT would be soon cluttered up by them.
|
We had discussion about this several times (Please search Lugnet).
Because TLG uses these days the colored numbers in the instructions, we try to
bring also this number to the user. The AIOI lets you choose to install these
parts or not.
I hope this answers your question.
cu
mikeheide
|
|
| |
In lugnet.cad, Michael Heidemann wrote:
| |
We had discussion about this several times (Please search Lugnet).
Because TLG uses these days the colored numbers in the instructions, we try
to bring also this number to the user. The AIOI lets you choose to install
these parts or not.
I hope this answers your question.
cu
mikeheide
|
I couldn’t find anything revelant by searching LUGNET, but I do see sense in
this... though if enough numbers were found, parts/ directory one day would
contain more of PC parts rather than real parts. Wouldn’t it make more sense to
at least move them into their own directory?
|
|
| |
In lugnet.cad, Michael Heidemann wrote:
| |
In lugnet.cad, Santeri Piippo wrote:
| |
What are the physical colour parts such as
this one
for? Wouldn’t it be more disk-space saving to rather have a list of coloured
part numbers? I have my hands on quite a lot of them through building
instructions, and I think that if one made a physical colour part of each
one of them the PT would be soon cluttered up by them.
|
We had discussion about this several times (Please search Lugnet).
Because TLG uses these days the colored numbers in the instructions, we try
to bring also this number to the user. The AIOI lets you choose to install
these parts or not.
I hope this answers your question.
cu
mikeheide
|
Unfortunately, I missed this discussion and haven’t stumbled on the magic search
phrase to dig it up again.
It strikes me that creating hard-colored parts for every part/color permutation
Lego ever has or ever will produce has a number of drawbacks:
- It’s duplicative. Linetype 0 has a color component to solve this problem for all past, present, future, and even non-existent combinations.
- It dramatically decreases the signal-to-noise ratio on the part tracker at a time when LDraw output is already moribund.
- It will clog the LDraw library with tens of thousands of utterly redundant “parts.”
- Physical-colored parts are not versatile in actual modeling.
Those are stacked against a single positive:
- They match one of Lego’s internal part database keys.
I think the drawbacks outweigh that one lonely positive by a large margin,
especially since that one positive could have been reproduced with a simple
lookup table—if it was even important to begin with.
Furthermore, the notion that the drawbacks of hard-colored parts will disappear
just by having a checkbox in a Windows-proprietary installer is also severely
problematic:
- LDraw cannot have “optional components” and still maintain any claim to be a common interchange format. Either everybody has the same LDraw, or we give up on the idea of sharing models.
- Installer option or no, maintaining and certifying all these needless parts is a bit like setting a horde of leaches on a hemorrhage patient. LDraw has produced no creative output in the last three years; must we really clog the arteries even more?
- The LDraw library should not be distributed solely via a proprietary installer!
I would like to see LDraw return to its heritage of enabling the creation of
cool new virtual creations by regaining its focus on delivering actual new part
files to its users. While LDraw has hardly been inactive, it also hasn’t been
following its core purpose in years. Hard-colors parts are just another
distraction from that mission.
Allen
|
|
| |
On Mon, 13 Apr 2009 03:12:29 GMT, Allen Smith wrote:
> Unfortunately, I missed this discussion and haven't stumbled on the magic
> search
> phrase to dig it up again.
>
> It strikes me that creating hard-colored parts for every part/color permutation
> Lego ever has or ever will produce has a number of drawbacks:
>
> * It's duplicative. Linetype 0 has a color component to solve this problem for
> all past, present, future, and even non-existent combinations.
> * It dramatically decreases the signal-to-noise ratio on the part tracker at a
> time when LDraw output is already moribund.
> * It will clog the LDraw library with tens of thousands of utterly redundant
> "parts."
> * Physical-colored parts are not versatile in actual modeling.
>
> Those are stacked against a single positive:
>
> * They match one of Lego's internal part database keys.
>
> I think the drawbacks outweigh that one lonely positive by a large margin,
> especially since that one positive could have been reproduced with a simple
> lookup table—if it was even important to begin with.
>
> Furthermore, the notion that the drawbacks of hard-colored parts will disappear
> just by having a checkbox in a Windows-proprietary installer is also severely
> problematic:
>
> * LDraw cannot have "optional components" and still maintain any claim to be a
> common interchange format. Either everybody has the same LDraw, or we give up
> on the idea of sharing models.
> * Installer option or no, maintaining and certifying all these needless parts
> is
> a bit like setting a horde of leaches on a hemorrhage patient. LDraw has
> produced no creative output in the last three years; must we really clog the
> arteries even more?
> * The LDraw library should not be distributed solely via a proprietary
> installer!
>
> I would like to see LDraw return to its heritage of enabling the creation of
> cool new virtual creations by regaining its focus on delivering actual new part
> files to its users. While LDraw has hardly been inactive, it also hasn't been
> following its core purpose in years. Hard-colors parts are just another
> distraction from that mission.
>
> Allen
Amen! Preach it Brother Allen! I agree with you on all fronts. In
the good news department - a part I first submitted 3 1/2 years ago
(40375) finally got certified this weekend.
But the pace of output for this stuff in painfully slow, and steps
need to be taken to speed it up, especially if it includes the bonuses
Allen already cited above, and even if it includes negatives such as
non-perfect parts that still need work slipping through as official.
Many parts like that made it in to the system early on, and that is
what made L-draw work.
Imagine if James had been submitting the 2x4 brick to the tracker
today... it is a fairly simple part so perhaps only a year or two
would have elapsed before it made the official list. I think this
whole system was designed originally so people could quickly start
virtually building. Lets work for ways to quickly and easily do that.
I've got another part (55423) in the system that has only 1 certify
vote after almost 2 years (thank you Philo), and it is an extremely
useful part that people actually need. Perhaps the reviewers are
afraid to take the time - I know I would be if I were a reviewer. The
stakes are too high with the way the bar is currently set - the
commitment to properly review a part is hours per part.
It would be better I think to look at the part from a wide angle and
send it through... if there are no glaring errors probably nobody will
ever notice them. If the little errors are ever a problem for anyone,
then can be fixed later as they are noticed. But in the mean time
there is another official part for people to use.
And as Allen mentioned, by no means should we be stressing the system
with surplus parts in physical colors to confrom to Lego's internal
numbering system that has changed in the past and will doubtless
change again some day. If anyone has a need to know what colors any
part is physically available in then that information can be looked up
separately. I'm sure some enterprising person will make a handy
L-draw add on color availability chart some day using existing online
references from peeron, bricklink or others, if it hasn't already
been done.
-Matt :)
-----------------------------------------------------
Matt Chiles
1006 Horseshoe Bend Rd
Centerville, WA 98613 USA
Phone: 509-773-5724
|
|
| |
In lugnet.cad, Allen Smith wrote:
> In lugnet.cad, Michael Heidemann wrote:
> > In lugnet.cad, Santeri Piippo wrote:
> > > What are the physical colour parts such as
> > > <http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/4206482.dat this one>
> > > for? Wouldn't it be more disk-space saving to rather have a list of
> > > coloured part numbers? I have my hands on quite a lot of them through
> > > building instructions, and I think that if one made a physical colour part
> > > of each one of them the PT would be soon cluttered up by them.
> >
> > We had discussion about this several times (Please search Lugnet).
> > Because TLG uses these days the colored numbers in the instructions, we try
> > to bring also this number to the user. The AIOI lets you choose to install
> > these parts or not.
> >
> > I hope this answers your question.
> >
> > cu
> > mikeheide
>
> Unfortunately, I missed this discussion and haven't stumbled on the magic
> search phrase to dig it up again.
>
> It strikes me that creating hard-colored parts for every part/color
> permutation Lego ever has or ever will produce has a number of drawbacks:
>
> * It's duplicative. Linetype 0 has a color component to solve this problem
> for all past, present, future, and even non-existent combinations.
> * It dramatically decreases the signal-to-noise ratio on the part tracker at
> a time when LDraw output is already moribund.
> * It will clog the LDraw library with tens of thousands of utterly redundant
> "parts."
> * Physical-colored parts are not versatile in actual modeling.
>
> Those are stacked against a single positive:
>
> * They match one of Lego's internal part database keys.
>
> I think the drawbacks outweigh that one lonely positive by a large margin,
> especially since that one positive could have been reproduced with a simple
> lookup table—if it was even important to begin with.
Allen,
I agree with you and would go a step further: I cannot see any benefit to have
alias parts for transparent and opaque parts, but all this is the territory of
the PT admins and I'm not going to mess around in their corner of the sandbox.
The only case where hard-colored parts with ItemID numbering could serve the
purpose is a special LDD library which would prevent LDD/LU ripping off parts
which are supported by LDD but NOT in the color you've chosen
in MLCad. Such a library would have nothing more than simple parts with a hard
coded color and a header title reflecting this:
-----------------------------------------------------
0 LDD Minifig Head with Evil Skeleton Skull Pattern - White
0 Name: 4162427.dat
0 Author: Willy Tschager [Holly-Wood]
0 !LDRAW_ORG Unofficial_Shortcut Physical_Colour
0 !LICENSE Redistributable under CCAL version 2.0 : see
CAreadme.txt
0 BFC CERTIFY CCW
1 15 0 0 0 1 0 0 0 1 0 0 0 1 3626bpa8.dat
0
-----------------------------------------------------
But as long LDD import parts solely based on DesignIDs the entire disussion is
superfluous.
w.
|
|
| |
In lugnet.cad, Matthew J. Chiles <mattchiles@gorge.net> wrote:
> I've got another part (55423) in the system that has only 1 certify
> vote after almost 2 years (thank you Philo), and it is an extremely
> useful part that people actually need. Perhaps the reviewers are
> afraid to take the time - I know I would be if I were a reviewer. The
> stakes are too high with the way the bar is currently set - the
> commitment to properly review a part is hours per part.
Sorry Matt but this is cheap. Everyone who has the skills to author a part has
all that's needed to review one. Instead of blaiming the reviewers go and ask
for review rights - it might takes hours to review a part but it takes less than
author one.
> It would be better I think to look at the part from a wide angle and
> send it through... if there are no glaring errors probably nobody will
> ever notice them. If the little errors are ever a problem for anyone,
> then can be fixed later as they are noticed. But in the mean time
> there is another official part for people to use.
This is already possible:
http://news.lugnet.com/announce/?n=3442
w.
|
|
| |
In lugnet.cad, Matthew J. Chiles <mattchiles@gorge.net> wrote:
SNIP
> I've got another part (55423) in the system that has only 1 certify
> vote after almost 2 years (thank you Philo), and it is an extremely
> useful part that people actually need. Perhaps the reviewers are
> afraid to take the time - I know I would be if I were a reviewer. The
> stakes are too high with the way the bar is currently set - the
> commitment to properly review a part is hours per part.
>
> It would be better I think to look at the part from a wide angle and
> send it through... if there are no glaring errors probably nobody will
> ever notice them. If the little errors are ever a problem for anyone,
> then can be fixed later as they are noticed. But in the mean time
> there is another official part for people to use.
SNIP
Reviewing is not a big deal for most parts.
Please see a good (but not at the current stage) tutorial here:
http://www.l3go.bugge.com/articles/Reviewing-parts-tutorial.shtml
I am with you if you like to have more reviewers on the PT.
I also often read the sentence like "could benefit from using..." and a novote.
I feel that there should be made a certify or hold in that cases because if the
author don't correct his part within 3 month you can correct that error without
permission!
Often I had use this procedere to push some parts that had long time only such
messages.
cu
mikeheide
|
|
|
