parts.lst: what currently maintained programs use it?

[Orion Pobursky]

Since Tim Gould has been working on revising mklist, I'm curious what modern LDraw programs actually rely on mklist. The only one I can think of off the top of my head is MLCad.

[Roland Melkert]

I currently don't use it for LDCad, but if the new version is going to include some very dynamic filtering capabilities, i could add support for it so people can share (some of) the bin content with other software.

I'm thinking multiple lists in a dedicated ldraw sub folder (or just the one parts.lst), which will be parsed and used to generate (a) part bin group(s) in LDCad.

[Tim Gould]

If you have any features you'd like me to add please let me know in the thread.

Tim

[Roland Melkert]

I'm not really looking for features myself, more a reason for me to support the file(s) mklist generates.

One being: shared part bin content among software. But the one giant parts.lst isn't that interesting for a single bin group's content, so the possibility to generate multiple files, based on some sort of rule set (or bat oriented multiple calls) would be very powerful in combination with e.g. regular expressions etc.

Any software could then look in e.g. in "<LDraw>" (or some specific subfolder) and read *.lst files for generating (additional) bin content.

[Tim Gould]

I think one file with multiple subsections might be easier.

eg.

Code:

parts.lst:
XXXX.dat    Description
XXXX.dat    Description
XXXX.dat    Description
XXXX.dat    Description
XXXX.dat    Description
unoffical.lst:
XXXX.dat    Description
XXXX.dat    Description
XXXX.dat    Description
XXXX.dat    Description
primitives.lst
XXXX.dat    Description
XXXX.dat    Description
etc.

This would require a major rewrite of my code but could be done I think.

Tim

[Roland Melkert]

Such a format works for me too, if that's the way you prefer it.

But will mlcad and other software skip those lines?

If not you could consider an 'index' kinda setup, a separate file holding the additional 'section' information.

[Orion Pobursky]

The reason I ask is because I feel that this method of doing business is sorely in need of a update. Unfortunately our hands are tied since MLCad is by far the most popular Windows LDraw program and it's not even close to being actively developed. If only Michael would either open source it or hand the reins off to someone more active...

[Tim Gould]

I'd probably do it in another file. eg. LDParts.lst

Tim

[Tim Gould]

Totally agree. I wrote this to ensure I could still use MLCad even if the long descriptions broke it. And then I got carried away.

Tim

[Scott Wardlaw]

I started doing this a while back, but almost nobody cared...

http://forums.ldraw.org/showthread.php?t...47#pid2747

[Roland Melkert]

If you goning to introduce a new file, you might want to take some time considering it's format. Cause it gives room for all kinds of things (like: section descriptions, mascots, etc) if you don't need to take legacy software in account.

[Orion Pobursky]

That's exactly what I want to do but just like the !COLOUR statements until/unless MLCad supports it then we're only talking to ourselves.

[Magnus Forsberg]

I was wondering where that little gem disappeared. I would really like to see a Library Manager.

Is it possible to make a program that not only makes lists of parts, but also manage the files?
I like to keep official and unofficial parts apart, so I have them in different folders, but I don't want to have both files i my folders, when scanning for new parts.
If I download a file that's been redesigned and published on the Part Tracker, today I have to manually move away the old file, to a third folder with "old files".

How does these programs handle duplicate files, with sometimes identical names? One in "Parts" and one in "Unofficial/Parts" folders.

[Tim Gould]

I would have cared if I'd seen it. But I'd guess it came in the middle of my huge work programming spell when the rest of the universe vanishes from my eyes.

Tim

[Scott Wardlaw]

MLCAD (and some other programs) use a scan order and take the first file that matches the part name. MLCAD's scan order is at the bottom of the MLCAD.ini file. Other programs (like LDView) are adopting an LDraw.ini file: http://news.lugnet.com/announce/?n=3854

I'd like more programs (including MLCAD) to adopt the LDraw.ini file for scanning for parts and primitives in order. I'll bring this up in the Steer Co.

My Library_Manager has the ability to download both official and unofficial part files. Currently it dumps them all in LDraw/Parts, and not any custom / unofficial directory, but maybe you can modify it to do so. I've been busy, but should be able to post the source code to it and the beginning of my parts editor program tonight.

If anyone wants to continue working on a Library_Manager, please post your intention here, so that myself and others may help.

Scott

[Scott Wardlaw]

Here is the source code to Library_Manager:

www.scottwardlaw.com/lego/Library_Manager.zip

And here are some screen shots:



I wish that I had the time to work on it more, but definitely not going to happen.

If anyone can use the source code, please let me know.

Thanks,
Scott W.

[Don Heyse]

Given the tardiness of this reply, I have to admit my claim to "currently maintained" status is somewhat shaky. However, for what it's worth, as seen in these pictures ldglite does still make use of the parts.lst file, and I think ldlist may also use it. Now if you'd asked about "actively used" programs I'd be on even shakier ground.