| |
In lugnet.cad.dev, Allen Smith wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part
number (yes, even on the Mac version Allan!), and the part title. Currently
I get these titles from PARTS.LST, but that is not sufficient, and it is a
short sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the original
LDraw distribution? You can’t rely on that being present. Not being able to
rely on a DOS utility, Bricksmith reads the part library and generates its
own XML parts list; I assume other programs do something similar.
|
snip
LPub does not need a total list of parts, so it doesn’t have to scan all the
paths. It does need the titles of parts that are used however. Since parts.lst
is a precomupted list of some of them, LPub reads it and puts the contents in an
associative array.
If we need the title for a part not in the array, we check the list of paths
(which now includes Unofficial/Parts, et. al.). If found, the part file is
opened, then title extracted and thrown in the associative array.
So, Willy, LPub supports the unofficial parts path stuff, including Helpers, and
Custom Parts. Do we want to add Development/Parts Development/P?
Development/P48?
So, this leads to a few more questions......
Allen,
You know those obtuse MLCad meta’s we talked about, like rotation step, buffer
exchange, GHOST? Sounds because LPub supports these, you might want to add them
to BrickSmith.
Don,
Did you get a chance to add the unofficial path support to LDGLite?
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In lugnet.cad.dev, Allen Smith wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part
number (yes, even on the Mac version Allan!), and the part title.
Currently I get these titles from PARTS.LST, but that is not sufficient,
and it is a short sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the
original LDraw distribution? You can’t rely on that being present. Not
being able to rely on a DOS utility, Bricksmith reads the part library
and generates its own XML parts list; I assume other programs do
something similar.
|
LPub does not need a total list of parts, so it doesn’t have to scan all the
paths. It does need the titles of parts that are used however. Since
parts.lst is a precomupted list of some of them, LPub reads it and puts the
contents in an associative array.
|
I believe a MAC version mklist utility used to generate the PARTS.LST
file comes bundled with the OS-X version of ldglite. Source code is
available, so anyone can build it on whatever platform they like.
There may be better ways to build the list, but PARTS.LST should always
be available as the least common denominator.
| |
Don,
Did you get a chance to add the unofficial path support to LDGLite?
|
Not yet, but soon...
Don
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> So, Willy, LPub supports the unofficial parts path stuff, including Helpers,
> and Custom Parts. Do we want to add Development/Parts Development/P?
> Development/P48?
Perfect - many thx! Don't think there is any need for "development" but
"<LDRAWDIR>LSynth" wouldn't hurt. You could then store all constraints and
synthesis parts in that folder without the need to mix them with the official
parts or rebuild Parts.lst, while I, as maintainer of the MLCad.ini, could
include a search path and scan for LSynth by default.
w.
|
|
| |
In lugnet.cad.dev, Willy Tschager wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > So, Willy, LPub supports the unofficial parts path stuff, including Helpers,
> > and Custom Parts. Do we want to add Development/Parts Development/P?
> > Development/P48?
>
> Perfect - many thx! Don't think there is any need for "development" but
> "<LDRAWDIR>LSynth" wouldn't hurt. You could then store all constraints and
> synthesis parts in that folder without the need to mix them with the official
> parts or rebuild Parts.lst, while I, as maintainer of the MLCad.ini, could
> include a search path and scan for LSynth by default.
>
> w.
I figured that Development would be use by parts authors. I was offering it as
an alternative to D:work_in_progress. LSynth it is.
Kev
|
|
|
