| |
The LEGO Elements Image Catalog, currently at <http://partsref.home.att.net/>,
is in the process of relocating to a new home on LUGNET. See it at
<http://www.lugnet.com/cad/ldraw/parts/ref>.
Right now, the catalog is at both locations. This will continue at least until
the next release of new parts for LDraw. After the next update, the catalog
will probably be removed from att.net site.
Steve
|
|
| |
In lugnet.cad.dev, Steve Bliss writes:
> The LEGO Elements Image Catalog, currently at <http://partsref.home.att.net/>,
> is in the process of relocating to a new home on LUGNET. See it at
> <http://www.lugnet.com/cad/ldraw/parts/ref>.
>
> Right now, the catalog is at both locations. This will continue at least • until
> the next release of new parts for LDraw. After the next update, the catalog
> will probably be removed from att.net site.
>
> Steve
YAY!... love this page.. use it all the time...
only Todd has a policy where set images are not to be linked to directly from
LUGNET (Pause)... how will this affect those of us who link to the parts ref
for piece auctions (ala Guarded Inn)?
J
|
|
| |
Jeff Boen wrote:
> YAY!... love this page.. use it all the time...
>
> only Todd has a policy where set images are not to be linked to directly from
> LUGNET (Pause)... how will this affect those of us who link to the parts ref
> for piece auctions (ala Guarded Inn)?
Arguably you're going to have to make copies of the images and host them
yourself. That's a downside. I didn't have too much guilt over having
AT&T pay for the traffic (presumably Steve isn't paying per byte the way
Todd is).
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
I could host the images if it makes it easier for people to use it,
or cheaper for LUGNET. (I don't have any restrictions on direct linking).
KL
In lugnet.cad.dev, Larry Pieniazek writes:
> Jeff Boen wrote:
>
> > YAY!... love this page.. use it all the time...
> >
> > only Todd has a policy where set images are not to be linked to directly • from
> > LUGNET (Pause)... how will this affect those of us who link to the parts ref
> > for piece auctions (ala Guarded Inn)?
>
> Arguably you're going to have to make copies of the images and host them
> yourself. That's a downside. I didn't have too much guilt over having
> AT&T pay for the traffic (presumably Steve isn't paying per byte the way
> Todd is).
>
> --
> Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
> - - - Web Application Integration! http://www.novera.com
> fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
>
> NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
In lugnet.cad.dev, Jeff Boen wrote:
> only Todd has a policy where set images are not to be linked to directly from
> LUGNET (Pause)... how will this affect those of us who link to the parts ref
> for piece auctions (ala Guarded Inn)?
Ooo, didn't think about that one. Hmm. I guess you'll need to copy the images
off to your own server. That's too bad.
BTW, the primary reason I wanted to move off the WorldNet site was because I
could never get an FTP connection to do updates. And because it's cool to have
contributed something to LUGNET. :)
Steve
|
|
| |
In lugnet.cad.dev, Kevin Loch writes:
> In lugnet.cad.dev, Larry Pieniazek writes:
> > Jeff Boen wrote:
> > > YAY!... love this page.. use it all the time...
> > > only Todd has a policy where set images are not to be linked to directly
> > > from LUGNET (Pause)... how will this affect those of us who link to the
> > > parts ref for piece auctions (ala Guarded Inn)?
> >
> > Arguably you're going to have to make copies of the images and host them
> > yourself. That's a downside. I didn't have too much guilt over having
> > AT&T pay for the traffic (presumably Steve isn't paying per byte the way
> > Todd is).
Well, like it says on the page,
"To reference a part image, when you already know the LDraw number for
that part, use the following URL format.
http://www.lugnet.com/cad/ldraw/parts/ref/images/<partno>.gif"
In other words, linking directly to these images is OK in this case.
> I could host the images if it makes it easier for people to use it,
> or cheaper for LUGNET. (I don't have any restrictions on direct linking).
These are relatively small images, so it's not really a problem, but thanks
anyway for the offer. :) Also, it's nice to have this type of image locally
because the height & width in pixels of each image can be fetched efficiently
on-the-fly rather than having to store them somewhere separate from the image.
BTW, Steve sent along a textfile with data extracted from DAT files, which
I can use to to generate HTML pages for categories and individual parts (like
he did already, but it hasn't been updated in a while) and for some wildcard
searching. So from that, there'll also be the opportunity to present people
with the option of linking to an HTML page or directly the images themselves
(whichever they prefer).
And ultimately, for the LUGNET Brictionary, the HTML pages will also be
dynamically created and cross-referenced into other DBs in the system,
including personal want lists and auctions, so the HTML pages will also be
more likely to be linked to than the raw images, because the HTML pages
will contain more useful information.
--Todd
|
|
| |
In lugnet.cad.dev, Steve Bliss writes:
> In lugnet.cad.dev, Jeff Boen wrote:
> > only Todd has a policy where set images are not to be linked to directly
> > from LUGNET (Pause)... how will this affect those of us who link to the
> > parts ref for piece auctions (ala Guarded Inn)?
>
> Ooo, didn't think about that one. Hmm. I guess you'll need to copy the
> images off to your own server. That's too bad.
No, it's OK: people can link directly to the images just as they did before
at the previous location. On the splash page, it even says how to refer to
the images at the new URL.
--Todd
|
|
| |
In lugnet.cad.dev, Todd Lehman writes:
> > Ooo, didn't think about that one. Hmm. I guess you'll need to copy the
> > images off to your own server. That's too bad.
>
> No, it's OK: people can link directly to the images just as they did
> before at the previous location. On the splash page, it even says how
> to refer to the images at the new URL.
I just added a statement on that page noting that direct links to the parts
images are OK. Just so there's no confusion. :-)
--Todd
|
|
| |
In lugnet.cad.dev, Todd Lehman writes:
> In other words, linking directly to these images is OK in this case.
Cool!
> And ultimately, for the LUGNET Brictionary, the HTML pages will also be
> dynamically created and cross-referenced into other DBs in the system,
> including personal want lists and auctions, so the HTML pages will also be
> more likely to be linked to than the raw images, because the HTML pages
> will contain more useful information.
Is there any desire to have povray rendered images for each part?
I still think that would be cool, even though the ldraw versions are more
useful for some things. It would also be nice to be able to either:
1. have all parts rendered in all colors (disk space hog?)
2. have parts rendered on the fly in the desired color (cpu hog!)
This is especially important with decorated parts.
It would also be nice to have 3 sizes of each part:
1. thumbnail (128x128)
2. normal size (whatever variable size the parts are now)
3. large (3x normal size)
KL
|
|
| |
Kevin Loch <kloch@opnsys.com> wrote in message news:FM32ur.BwF@lugnet.com...
> In lugnet.cad.dev, Todd Lehman writes:
> > In other words, linking directly to these images is OK in this case.
>
> Cool!
> > And ultimately, for the LUGNET Brictionary, the HTML pages will also be
> > dynamically created and cross-referenced into other DBs in the system,
> > including personal want lists and auctions, so the HTML pages will also be
> > more likely to be linked to than the raw images, because the HTML pages
> > will contain more useful information.
>
>
> Is there any desire to have povray rendered images for each part?
> I still think that would be cool, even though the ldraw versions are more
> useful for some things. It would also be nice to be able to either:
I agree. Some parts--especially those with lots of rounded surfaces--can be
hard to make out in LDraw. POVRAY works much better for these parts (and for
decorated parts, as Kevin noted.)
-John Van
|
|
| |
In lugnet.cad.dev, Kevin Loch writes:
> Is there any desire to have povray rendered images for each part?
IMHO, the best thing is having both (a) super-quick-loading GIFs and (b)
high-quality POV JPEGs, and then letting the user decide which one to view.
A while back, someone even suggested having spinning/rotating POV-rendered
images for each part in MPEG, or DAT->VRML conversions... :)
I'm not super-duper POV-fluent, but if anyone wants to make POV-rendered
versions of the LDraw parts, I can stick 'em in the partsref as an alternate
view, if that's OK with Steve.
--Todd
|
|
| |
One thing I noticed with the DAT explorer is that POV rendered images
look _MUCH_ better with the lossless PNG format thatn with JPEG.
Perhaps appropriate use of the JPEG smoothing function would help
the the tests I did looked bad even at 100% quality.
KL
In lugnet.cad.dev, Todd Lehman writes:
> In lugnet.cad.dev, Kevin Loch writes:
> > Is there any desire to have povray rendered images for each part?
>
> IMHO, the best thing is having both (a) super-quick-loading GIFs and (b)
> high-quality POV JPEGs, and then letting the user decide which one to view.
> A while back, someone even suggested having spinning/rotating POV-rendered
> images for each part in MPEG, or DAT->VRML conversions... :)
>
> I'm not super-duper POV-fluent, but if anyone wants to make POV-rendered
> versions of the LDraw parts, I can stick 'em in the partsref as an alternate
> view, if that's OK with Steve.
>
> --Todd
|
|
| |
Todd Lehman wrote:
> And ultimately, for the LUGNET Brictionary, the HTML pages will also be
> dynamically created and cross-referenced into other DBs in the system,
> including personal want lists and auctions, so the HTML pages will also be
> more likely to be linked to than the raw images, because the HTML pages
> will contain more useful information.
Speaking of which... I just posted my wants list. I want hundreds of
most of the items on it. Someone pointed out to me that if I could tell
of sets that had large quantities of the parts I might get better
responses.
Given the current state of things, how would I go about determining sets
that are likely to be good candidates? I know Todd and some others
answered this question by hand at one point, but now I want to do it for
every part on my list
http://mrfws1.innovation.com/~larryp/parts_want_list.html
which is a bunch of different parts.
I'd pay some nominal sum for this information if it would help shake it
loose. I am not sure how to go about determining it at this point...
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
In lugnet.cad.dev, Kevin Loch writes:
> In lugnet.cad.dev, Todd Lehman writes:
> > In other words, linking directly to these images is OK in this case.
>
> Cool!
> > And ultimately, for the LUGNET Brictionary, the HTML pages will also be
> > dynamically created and cross-referenced into other DBs in the system,
> > including personal want lists and auctions, so the HTML pages will also be
> > more likely to be linked to than the raw images, because the HTML pages
> > will contain more useful information.
>
>
> Is there any desire to have povray rendered images for each part?
> I still think that would be cool, even though the ldraw versions are more
> useful for some things. It would also be nice to be able to either:
>
> 1. have all parts rendered in all colors (disk space hog?)
> 2. have parts rendered on the fly in the desired color (cpu hog!)
>
> This is especially important with decorated parts.
>
> It would also be nice to have 3 sizes of each part:
>
> 1. thumbnail (128x128)
> 2. normal size (whatever variable size the parts are now)
> 3. large (3x normal size)
>
>
> KL
I Started this Several Weeks ago, I have already run Pov-Ray for the Thumbs
and the Large Size. I have only the two sizes done so far. What would you
call normal Size, I had not figured out a good third size any suggestions?
All pngs, 128x96 and 512x384. However this was a done in a batch so some
parts are rotated in a useless direction. You can view or scoop them off my
ftp server at
ftp://24.113.91.23/pub/lego_parts
Grab the Tarballs if any one wants to host them or needs the whole set.
As to extra color sets....its 100MB + 196 hrs per color...... [/;-)
Keep at it
DaveG
|
|
| |
Excellent!
After looking at them I think that other perspectives are more important
than colors. Have you tried experimenting with the ambient light option
in povray? I don't think l3p gives you that option but you can modify the
pov files l3p produces.
KL
In lugnet.cad.dev, David Goeb writes:
> In lugnet.cad.dev, Kevin Loch writes:
> > In lugnet.cad.dev, Todd Lehman writes:
> > > In other words, linking directly to these images is OK in this case.
> >
> > Cool!
> > > And ultimately, for the LUGNET Brictionary, the HTML pages will also be
> > > dynamically created and cross-referenced into other DBs in the system,
> > > including personal want lists and auctions, so the HTML pages will also be
> > > more likely to be linked to than the raw images, because the HTML pages
> > > will contain more useful information.
> >
> >
> > Is there any desire to have povray rendered images for each part?
> > I still think that would be cool, even though the ldraw versions are more
> > useful for some things. It would also be nice to be able to either:
> >
> > 1. have all parts rendered in all colors (disk space hog?)
> > 2. have parts rendered on the fly in the desired color (cpu hog!)
> >
> > This is especially important with decorated parts.
> >
> > It would also be nice to have 3 sizes of each part:
> >
> > 1. thumbnail (128x128)
> > 2. normal size (whatever variable size the parts are now)
> > 3. large (3x normal size)
> >
> >
> > KL
>
> I Started this Several Weeks ago, I have already run Pov-Ray for the Thumbs
> and the Large Size. I have only the two sizes done so far. What would you
> call normal Size, I had not figured out a good third size any suggestions?
>
> All pngs, 128x96 and 512x384. However this was a done in a batch so some
> parts are rotated in a useless direction. You can view or scoop them off my
> ftp server at
> ftp://24.113.91.23/pub/lego_parts
>
> Grab the Tarballs if any one wants to host them or needs the whole set.
> As to extra color sets....its 100MB + 196 hrs per color...... [/;-)
>
> Keep at it
> DaveG
|
|
| |
In lugnet.cad.dev, Kevin Loch writes:
> Excellent!
>
> After looking at them I think that other perspectives are more important
> than colors. Have you tried experimenting with the ambient light option
> in povray? I don't think l3p gives you that option but you can modify the
> pov files l3p produces.
>
> KL
Yeah I was thinking that the third size should be a composite of four views
top, left, bottom, and right. Should the floor be kept in this kind of view?
Ie: Rotate Part over floor rather than 4 Cameras, nuking the floor only on
the bottom view. Also is the 512x384 nice size for this or should it be bigger?
If the Pngs are too dark on PC's I can Run a Gamma shift over file set or
do they need higher contrast, Different color floor?
>
> In lugnet.cad.dev, David Goeb writes:
> > In lugnet.cad.dev, Kevin Loch writes:
> > > In lugnet.cad.dev, Todd Lehman writes:
> > > > In other words, linking directly to these images is OK in this case. • [big snip]
> > > KL
[small snip]
> > DaveG
|
|
| |
In lugnet.cad.dev, Todd Lehman wrote:
> In lugnet.cad.dev, Kevin Loch writes:
> > Is there any desire to have povray rendered images for each part?
>
> IMHO, the best thing is having both (a) super-quick-loading GIFs and (b)
> high-quality POV JPEGs, and then letting the user decide which one to view.
> A while back, someone even suggested having spinning/rotating POV-rendered
> images for each part in MPEG, or DAT->VRML conversions... :)
>
> I'm not super-duper POV-fluent, but if anyone wants to make POV-rendered
> versions of the LDraw parts, I can stick 'em in the partsref as an alternate
> view, if that's OK with Steve.
That's fine with me. The only downside is applying updates. When new parts are
released for LDraw, I don't update individual partsref images and pages, I just
regenerate the whole shebang. So any manual edits would probably get
overwritten. Anyone got a good idea on avoiding this?
Actually, if parts/ref is going to be a reference specifically to the LDraw
library, I need to un-fix some stuff.
During the last update, I made some arbitrary decisions to clean up some of the
categories, consolidating some some categories which were odd or too small, and
splitting up some large categories into multiples. Some of this was
accomplished by hand-editing my local install of the parts-library. Which made
it more user-friendly, but less accurate as a reference to the LDraw library.
So maybe I should install a vanilla copy of LDraw, generate a new partsref, and
upload it.
Steve
|
|
| |
Steve Bliss wrote:
> In lugnet.cad.dev, Todd Lehman wrote:
> > I'm not super-duper POV-fluent, but if anyone wants to make POV-rendered
> > versions of the LDraw parts, I can stick 'em in the partsref as an alternate
> > view, if that's OK with Steve.
> That's fine with me. The only downside is applying updates. When new parts are
> released for LDraw, I don't update individual partsref images and pages, I just
> regenerate the whole shebang. So any manual edits would probably get
> overwritten. Anyone got a good idea on avoiding this?
Are you familiar with the make utility? It allows you to describe an
arbitrary set of modules, with their associated interdependencies, and then
re-build only the modules which have changed and modules dependant upon them.
Of course, using make would require that you can build each image and html
file from the command-line, one at a time.
Cheers,
- jsproat
--
Jeremy H. Sproat <jsproat@io.com> ~~~ http://www.io.com/~jsproat/
It's a fine line between marketing and grand theft. -- Scott Adams
|
|
| |
In lugnet.cad.dev, Sproaticus wrote:
> Steve Bliss wrote:
> > In lugnet.cad.dev, Todd Lehman wrote:
> > > I'm not super-duper POV-fluent, but if anyone wants to make POV-rendered
> > > versions of the LDraw parts, I can stick 'em in the partsref as an alternate
> > > view, if that's OK with Steve.
> > That's fine with me. The only downside is applying updates. When new parts are
> > released for LDraw, I don't update individual partsref images and pages, I just
> > regenerate the whole shebang. So any manual edits would probably get
> > overwritten. Anyone got a good idea on avoiding this?
>
> Are you familiar with the make utility? It allows you to describe an
> arbitrary set of modules, with their associated interdependencies, and then
> re-build only the modules which have changed and modules dependant upon them.
Yep, I'm familiar with make. I even went to look for one once. Do you know how
hard it is to search the net for 'make'? I never could figure out a decent set
of search-words...
Oh, wait. I've got a make.exe with my old copy of Turbo Pascal. And another
with GNAT-Ada. Hmmm... Nope, no docs on either.
Anyone got make docs?
One problem with make is that sometimes, the image file will be based on an
outdated DAT, but the image will still have a more recent datestamp than the
current DAT. And make can't deal with that (unless someone changed make and
didn't tell me).
For example, I wrote a part-file. It's released in an update. After the new
update goes out, I notice a problem, and submit a fixed file. The fixed file
won't be released until the following update, which could be a month or more.
In the meantime, I install the just-released update, rebuild partsref using
make. An image file is generated for the new part. When the next update is
released, it will have the fixed file, but the datestamp on the fixed DAT will
be older than the datestamp on the image.
> Of course, using make would require that you can build each image and html
> file from the command-line, one at a time.
Which is not a big deal, in terms of how long it will take to process, if only
the *changed* files are being updated.
One problem would be if make isn't smart enough to wait until the rendering
program completes, which is a problem if the rendering program is Windows-based.
Steve
|
|
| |
Steve Bliss wrote:
> Yep, I'm familiar with make. I even went to look for one once. Do you know how
> hard it is to search the net for 'make'? I never could figure out a decent set
> of search-words...
You could try the version which comes with Cynwin32:
http://sourceware.cygnus.com/cygwin/
I've used Beta 20.1; it seems pretty stable. If you're not too keen on using
the Unix sub-layer (slow), try dmake:
http://www.wticorp.com/dmake/
Hmmm, it seems to have gone commercial -- you have to *pay* for the binaries.
Arg. Well, if you don't mind paying homage to the Great Redmond Satan,
there's always Microsoft NMake:
ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
> Anyone got make docs?
For GNU make:
http://www.delorie.com/gnu/docs/make/make_toc.html
> One problem with make is that sometimes, the image file will be based on an
> outdated DAT, but the image will still have a more recent datestamp than the
> current DAT. And make can't deal with that (unless someone changed make and
> didn't tell me).
> For example, I wrote a part-file. It's released in an update. After the new
> update goes out, I notice a problem, and submit a fixed file. The fixed file
> won't be released until the following update, which could be a month or more.
> In the meantime, I install the just-released update, rebuild partsref using
> make. An image file is generated for the new part. When the next update is
> released, it will have the fixed file, but the datestamp on the fixed DAT will
> be older than the datestamp on the image.
You'd get this in any situation where you mix your development environment
with your everyday environment.
One alternative is to put a rule into your makefile, e.g. "clean", which will
delete all output image files. But this sorta defeats the purpose of using a
makefile.
> > Of course, using make would require that you can build each image and html
> > file from the command-line, one at a time.
> Which is not a big deal, in terms of how long it will take to process, if only
> the *changed* files are being updated.
> One problem would be if make isn't smart enough to wait until the rendering
> program completes, which is a problem if the rendering program is Windows-based.
Oh. Yah, that'd be a problem.
Within the shell that comes with WinNT 4.0 anyway, you can go "start /wait
ldlite somedat.dat", and the shell will wait for the process to end. I don't
know if this works on Win95/98.
Cheers,
- jsproat
--
Jeremy H. Sproat <jsproat@io.com> ~~~ http://www.io.com/~jsproat/
Arthur, I have POCKETS!!!
|
|
| |
Steve Bliss wrote:
> One problem with make is that sometimes, the image file will be based on an
> outdated DAT, but the image will still have a more recent datestamp than the
> current DAT. And make can't deal with that (unless someone changed make and
> didn't tell me).
This is kludgy but might work. Details left as an exercise. Your problem
is that what you want is to know when a file is *new to YOU* not what
it's timestamp is.
Keep two complete sets of .dat files. One is an image of the state of
files, but with timestamps preserved. The other one is an image, but
with timestamps as of when YOU received them.
Every time you get an update, use touch or something similar to make the
files in the update have the date that you received them (on a copy).
Apply the original update to your original image. Apply the touched
update to your "as received" image.
Now let make dependency analysis use the "as received" directory to work
from and bob's your uncle.
I think.
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
I haven't gotten any nibbles, can someone suggest a group better suited
to answering this question?
Larry Pieniazek wrote:
> Speaking of which... I just posted my wants list. I want hundreds of
> most of the items on it. Someone pointed out to me that if I could tell
> of sets that had large quantities of the parts I might get better
> responses.
>
> Given the current state of things, how would I go about determining sets
> that are likely to be good candidates? I know Todd and some others
> answered this question by hand at one point
<for one part>
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
[should've snipped the ng list, but I didn't--couldn't decide which to
keep/exclude]
In lugnet.cad.dev, Sproaticus wrote:
> You'd get this in any situation where you mix your development environment
> with your everyday environment.
So, as both the new Keeper of the LDraw Library and the Keeper of the Partsref
Pages, I could build a make, and apply it everytime I get new candidate files
for the parts library. That'd work, but it assumes that one person is doing
both jobs.
> Within the shell that comes with WinNT 4.0 anyway, you can go "start /wait
> ldlite somedat.dat", and the shell will wait for the process to end. I don't
> know if this works on Win95/98.
woohoo! The start /wait option works in Win98, too! That *is* good news.
Steve
|
|
| |
In lugnet.cad.dev, Larry Pieniazek wrote:
> Steve Bliss wrote:
>
> > One problem with make is that sometimes, the image file will be based on an
> > outdated DAT, but the image will still have a more recent datestamp than the
> > current DAT. And make can't deal with that (unless someone changed make and
> > didn't tell me).
>
> This is kludgy but might work. Details left as an exercise. Your problem
> is that what you want is to know when a file is *new to YOU* not what
> it's timestamp is.
I'm going to need to keep a vanilla installation, just for partsref generation.
It's too tempting to make minor edits to part files in my regular installation.
And, if I'm going to have two copies of LDraw, I'd rather have "working" and
"partsref" than "original" and "touched".
Hmm. How about this:
Receive new update file.
Expand new update, in a temp directory.
Touch all files in temp directory.
Copy files from temp to partsref copy of ldraw.
Make partsref.
Don't touch partsref copy of ldraw before next update.
Steve
|
|
| |
In lugnet.cad.dev, Larry Pieniazek wrote:
> I haven't gotten any nibbles, can someone suggest a group better suited
> to answering this question?
>
> Larry Pieniazek wrote:
>
> > Speaking of which... I just posted my wants list. I want hundreds of
> > most of the items on it. Someone pointed out to me that if I could tell
> > of sets that had large quantities of the parts I might get better
> > responses.
> >
> > Given the current state of things, how would I go about determining sets
> > that are likely to be good candidates? I know Todd and some others
> > answered this question by hand at one point
>
> <for one part>
lugnet.general?
lugnet.helpwanted?
The current problem is that there aren't that many published inventories for
current sets. So you need to hook up to someone who is A-R enough to inventory
everything themselves,.
Steve
|
|
| |
Steve Bliss wrote:
> The current problem is that there aren't that many published inventories for
> current sets. So you need to hook up to someone who is A-R enough to inventory
> everything themselves,.
Todd and Joshua D. have an amazing number inventoried, between them. At
least that's my suspicion.
It's convincing them to make the data available in a format I can run
reverse queries against that is the hard part.
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
Larry Pieniazek wrote:
>
> Todd Lehman wrote:
>
> > And ultimately, for the LUGNET Brictionary, the HTML pages will also be
> > dynamically created and cross-referenced into other DBs in the system,
> > including personal want lists and auctions, so the HTML pages will also be
> > more likely to be linked to than the raw images, because the HTML pages
> > will contain more useful information.
>
> Speaking of which... I just posted my wants list. I want hundreds of
> most of the items on it. Someone pointed out to me that if I could tell
> of sets that had large quantities of the parts I might get better
> responses.
>
> Given the current state of things, how would I go about determining sets
> that are likely to be good candidates? I know Todd and some others
> answered this question by hand at one point, but now I want to do it for
> every part on my list
>
> http://mrfws1.innovation.com/~larryp/parts_want_list.html
>
> which is a bunch of different parts.
>
> I'd pay some nominal sum for this information if it would help shake it
> loose. I am not sure how to go about determining it at this point...
I'm not sure I want to do them all (though the list was much shorter
than I thought it would be),
but here's a start, the very first on the list.
Here are the sets (that I know of) released since 1992, with black 1x1
bricks,
sorted reverse on quantity, all sets that have quantity 10 or more:
1x1 Brick
Qty Set Set Name Year Theme
--- ---- ---------------------------- ---------- ----------------------
29 6079 Dark Forest Fortress 1996 Dark Forest
26 8880 Super Car 1994 Model
24 6086 Black Knight's Castle 1992 Black Knights
22 2146 LEGO Value Pack 1996 (Build-N-Store Chest)
22 6286 Skull's Eye Schooner 1993 Pirates
21 6082 Fire Breathing Fortress 1993 Dragon Masters
19 6090 Royal Knights Castle 1995 Royal Knights
18 1845 20th Anniversary Jackpot Buc 1993 (Bucket)
16 1708 Blue Ribbon Savings Bucket 1994 (Bucket)
14 6281 Pirates Perilous Pitfall 1997 Pirates
13 1906 Majisto's Tower 1994 Dragon Masters
13 6289 Red Beard Runner 1996 Pirates
12 1743 400 pc Brick Box 1995, 1996 (Build-N-Store Chest)
11 6494 Mystic Mountain Time Lab 1996 Time Cruisers
10 5581 Magic Flash 1993 Model
10 6076 Dark Dragon's Den 1993 Dragon Masters
10 6249 Pirates Ambush 1997 Pirates
10 6397 Gas N' Wash Express 1992 Recreation
10 6552 Rocky River Retreat 1993, 1994 Recreation
(This is the sort of thing you're looking for, right?)
[No guarantees of accuracy and so forth, use info at your own risk, et
cetera.]
-- joshua
Postscript: In case you're interested, the leader for this is 6085 Black
Monarch's
Castle, from 1988, with quantity 39.
|
|
| |
Steve Bliss wrote in message ...
[ ... snip ... ]
>
> Anyone got make docs?
There is a very good Make book available from O'Reilly & Associates,
_Managing Software Projects with Make_. I have found that this book always
seems to have an example for something I was trying to do. Also, if you
have access to a Unix system, the make man page tends to be pretty thorough
as well.
Mike - mike_walsh@mindspring.com
http://members.tripod.com/mike_walsh
|
|
| |
Mike Walsh wrote:
> There is a very good Make book available from O'Reilly & Associates,
> _Managing Software Projects with Make_. I have found that this book always
> seems to have an example for something I was trying to do. Also, if you
> have access to a Unix system, the make man page tends to be pretty thorough
> as well.
Oh, I dunno about O'Reilly... :-) Their stuff is spotty. It varies from
good, up through Insanely Great, all the way to YOU CAN'T LIVE WITHOUT
THIS BOOK. I wish they'd just pick a quality level and stick to it.
:-)
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
Larry Pieniazek wrote:
> Mike Walsh wrote:
> > There is a very good Make book available from O'Reilly & Associates,
> > _Managing Software Projects with Make_. I have found that this book always
> > seems to have an example for something I was trying to do. Also, if you
> > have access to a Unix system, the make man page tends to be pretty thorough
> > as well.
> Oh, I dunno about O'Reilly... :-) Their stuff is spotty. It varies from
> good, up through Insanely Great, all the way to YOU CAN'T LIVE WITHOUT
> THIS BOOK. I wish they'd just pick a quality level and stick to it.
Yah. Keeping my _sed & awk_ and _Programming Perl_ within reach isn't a
matter of life and death -- it's much more important than that.
But make is really a simple tool. I wonder just how useful an entire book for
it would be. The last one I saw quickly degenerated into Stupid Make Tricks,
which typically were no more tricky than using shell commands or spawning awk
and dc.
Cheers,
- jsproat
[f-ups set to .off-topic.geek]
--
Jeremy H. Sproat <jsproat@io.com> ~~~ http://www.io.com/~jsproat/
Arthur, I have POCKETS!!!
|
|
| |
Sproaticus wrote:
> But make is really a simple tool. I wonder just how useful an entire book for
> it would be. The last one I saw quickly degenerated into Stupid Make Tricks,
> which typically were no more tricky than using shell commands or spawning awk
> and dc.
MSPwM is more than just stupid Make tricks. It's a great book. Make may
be a simple tool, like so many other unix tools, but you can do very
very complex things with it which is why it's such a great tool...
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ ref: lar, 1/2 $$ to lugnet.
NOTE: Soon to be lpieniazek@tsisoft.com :-)
|
|
| |
In lugnet.off-topic.geek, Larry Pieniazek writes:
> Sproaticus wrote:
>
> MSPwM is more than just stupid Make tricks. It's a great book. Make may
> be a simple tool, like so many other unix tools, but you can do very
> very complex things with it which is why it's such a great tool...
Read the GNU Make How-to. That shoudl give you all the info you need =)
-Earle
------------------------------------------------
The Solution to the Bulk LEGO Problem
ByTheBrick http://www.EarlesHouse.com/LEGO
------------------------------------------------
|
|
|
