The 2020-01 LDraw Parts Update has been now been released. This adds 771 new files to the core library, including 444 new parts and 22 new primitives. Updated versions of the colour definition files (LDConfig.ldr and LDCfgalt.ldr) that have been available for download since May are included in this release.
Thanks are due to all the part authors who created or corrected parts for this release. The small, but dedicated, band of reviewers also play an important role in keeping files moving through the Parts Tracker and deserve just as much credit.
You can preview the new parts in 2020-01
here, and download the zip-file update or Windows install package
here. Alternatively you can use the LDView menu option File | Check for Library Updates... to install the update.
Thanks Chris!
Also, I think this is the first official update with texture images. A cool milestone for us.
Awesome!
Thanks heaps to everyone for your hard work.
I do notice that the complete.zip file contains two directories: LDraw and ldraw.
The new and updated files appear to be in LDraw.
Is this intended?
(2020-06-28, 22:31)Richard Speyer Wrote: [ -> ]Awesome!
Thanks heaps to everyone for your hard work.
I do notice that the complete.zip file contains two directories: LDraw and ldraw.
The new and updated files appear to be in LDraw.
Is this intended?
Not a big issue on case-insensitive Windows, but could be on other platforms. Thanks for reporting!
I find this to be very strange. I don't get a file like that. Mine contain a single folder "ldraw".
Is it correct that the file complete.zip doesn't contain all the new parts, and I have to manually
add the content of ldcad2001.zip into the correct folder?
(2020-06-29, 15:22)Magnus Forsberg Wrote: [ -> ]I find this to be very strange. I don't get a file like that. Mine contain a single folder "ldraw".
Is it correct that the file complete.zip doesn't contain all the new parts, and I have to manually
add the content of ldcad2001.zip into the correct folder?
I just downloaded the complete.zip. It only has one LDraw folder.
(2020-06-28, 22:31)Richard Speyer Wrote: [ -> ]Awesome!
Thanks heaps to everyone for your hard work.
I do notice that the complete.zip file contains two directories: LDraw and ldraw.
The new and updated files appear to be in LDraw.
Is this intended?
No, not intended. This is a problem. The intention was to change the folder inside the zip archive from ldraw to LDraw to better reflect the LDraw branding. All the existing files AND the 2020-01 updates should have been in LDraw. I'll post when it has been fixed.
(2020-06-29, 16:29)Chris Dee Wrote: [ -> ]No, not intended. This is a problem. The intention was to change the folder inside the zip archive from ldraw to LDraw to better reflect the LDraw branding. All the existing files AND the 2020-01 updates should have been in LDraw. I'll post when it has been fixed.
The complete.zip now contains just an LDraw folder. Apologies for this hiccup.
(2020-06-29, 17:16)Chris Dee Wrote: [ -> ]The complete.zip now contains just an LDraw folder. Apologies for this hiccup.
This will likely cause problems with LDView running on Linux. All previous zips had "ldraw" in them, and now it is switching to LDraw. So, LDView's auto-update mechanism is likely to totally fail on case-sensitive file systems (which are default on Linux). Even the initial might fail there, since it looks for "ldraw" and not "LDraw". (That
might succeed, due to my support for case-insensitive part file lookups, but I don't think that case-insensitive code extends to the ldraw directory itself. However, even if it does succeed it will slow LDView down a great deal, since the case-insensitive lookups are
much slower when they have to be used.)
I
strongly feel that this particular branding effort should be abandoned immediately.
(2020-06-29, 18:29)Travis Cobbs Wrote: [ -> ]I strongly feel that this particular branding effort should be abandoned immediately.
The name change sits in the LDraw root folder, imho this shouldn't influence the part lookup handling.
On a case sensitive system the only thing in need of change is the LDraw library location path option itself as it points to the wrong location when using ldraw.
So if a user unzips complete.zip it will create LDraw alongside the existing ldraw one, while all tools will keep pointing to the ldraw one.
On Windows it will just merge with the existing one if any.
Tools using complete.zip as is might have problems though, if they are looking for a hardcoded ldraw subfolder.
LDCad will use the first (recursive) subfolder containing a parts and or p folder, it doesn't care how the folder is named.
(2020-06-29, 18:29)Travis Cobbs Wrote: [ -> ]I strongly feel that this particular branding effort should be abandoned immediately.
I asked for this change. It makes no sense trying to strength the brand by using "LDraw" instead of "Ldraw" or "ldraw" when we don't use it in the very first place.
w.
I'm glad that a lot of part in the HOLD limbo for years finally made it into the official library.
w.
Thanks everyone for your work leading to that achievement!
(2020-06-30, 10:36)Willy Tschager Wrote: [ -> ]I'm glad that a lot of part in the HOLD limbo for years finally made it into the official library.
w.
Time to address the next batch!
(2020-06-30, 10:20)Willy Tschager Wrote: [ -> ]I asked for this change. It makes no sense trying to strength the brand by using "LDraw" instead of "Ldraw" or "ldraw" when we don't use it in the very first place.
w.
... and by doing so, I assumed that you had thought this through and gained acceptance from the SteerCo.
(2020-06-29, 21:23)Roland Melkert Wrote: [ -> ]The name change sits in the LDraw root folder, imho this shouldn't influence the part lookup handling.
On a case sensitive system the only thing in need of change is the LDraw library location path option itself as it points to the wrong location when using ldraw.
So if a user unzips complete.zip it will create LDraw alongside the existing ldraw one, while all tools will keep pointing to the ldraw one.
On Windows it will just merge with the existing one if any.
Tools using complete.zip as is might have problems though, if they are looking for a hardcoded ldraw subfolder.
LDCad will use the first (recursive) subfolder containing a parts and or p folder, it doesn't care how the folder is named.
LDView's part lookups should work fine.
However, LDView's code that automatically downloads and automatically updates the LDraw library assumes that all files inside both complete.zip and all the update zips will be located inside a directory named "ldraw". If those zips didn't have a directory name at all, then things would be fine. I would have just unzipped them into whatever the user chose as their LDraw directory. But since they do (and always have) put the files in a subdirectory, changing that directory name will almost certainly completely break my auto-install and auto-update functionality any time the LDraw directory is on a case-sensitive file system. (Note: I haven't actually tested this, since I don't personally have a working Linux install. But I am almost positive that it will not work.)
Thank you everyone for the release!!
I'm so glad that my first part 3010p0f and more come to official library.
I appreciate reviewers for a lot of advice and patience.
This will be a very memorable milestone for me.
I'll continue authoring more parts for next release 2020-02!!
(2020-06-30, 21:16)Takeshi Takahashi Wrote: [ -> ]Thank you everyone for the release!!
I'm so glad that my first part 3010p0f and more come to official library.
I appreciate reviewers for a lot of advice and patience.
This will be a very memorable milestone for me.
I'll continue authoring more parts for next release 2020-02!!
Welcome aboard, glad to have you, and congrats. Always a great feeling to have a part of yours released.
(2020-06-29, 18:29)Travis Cobbs Wrote: [ -> ]This will likely cause problems with LDView running on Linux. All previous zips had "ldraw" in them, and now it is switching to LDraw. So, LDView's auto-update mechanism is likely to totally fail on case-sensitive file systems (which are default on Linux). Even the initial might fail there, since it looks for "ldraw" and not "LDraw". (That might succeed, due to my support for case-insensitive part file lookups, but I don't think that case-insensitive code extends to the ldraw directory itself. However, even if it does succeed it will slow LDView down a great deal, since the case-insensitive lookups are much slower when they have to be used.)
I strongly feel that this particular branding effort should be abandoned immediately.
Following discussion, this change has been reverted. The complete.zip and lcad2001.zip downloads now only contain an ldraw (all lower case) folder.
Windows users should not have been impacted by this change, but Linux users are recommended to remove the (mixed case) LDraw folder and re-install this parts update, which should now place the new and updated files in the (lower case) ldraw folder.
(2020-07-01, 6:36)Chris Dee Wrote: [ -> ]Following discussion, this change has been reverted. The complete.zip and lcad2001.zip downloads now only contain an ldraw (all lower case) folder.
Windows users should not have been impacted by this change, but Linux users are recommended to remove the (mixed case) LDraw folder and re-install this parts update, which should now place the new and updated files in the (lower case) ldraw folder.
Thanks, Chris. I really appreciate it.
Yes, also congratulations, happy to have you on board,
and please stick with us - we know that the process of parts going through the Parts Tracker sometimes can appear slow -
but we all have a non-Ldraw real life in addition.
We are really trying our best to keep things going here, many for lots of years already.
Thanks for putting your effort into this small virtual universe.
(2020-06-30, 21:16)Takeshi Takahashi Wrote: [ -> ]Thank you everyone for the release!!
I'm so glad that my first part 3010p0f and more come to official library.
I appreciate reviewers for a lot of advice and patience.
This will be a very memorable milestone for me.
I'll continue authoring more parts for next release 2020-02!!
I'm likewise happy to make my official library "debut" in this release, with my 3069bpt7 (plus some corrections to the 6L bar)! Thanks to the reviewers for getting these through, and perhaps my small remaining bunch of parts will follow soon. :-)
Hopefully it won't be long before I can tackle something with some actual geometry (like that Model Team wheel I've been needing…)!
93220p04.dat - Minifig Baseball Bat with Three Metallic Silver Diamonds With Rivets Pattern
has to be renamed to:
93220p04.dat - Minifig Baseball Bat with Three Metallic Silver Diamonds _with_ Rivets Pattern
3626bp8a.dat - Minifig Head with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud with Pierced Base)
has to be renamed to:
3626bp8a.dat - Minifig Head _Female_ with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud with Pierced Base)
3626cp8a.dat - Minifig Head with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud)
has to be renamed to:
3626cp8a.dat - Minifig Head _Female_ with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud)
24076p02.dat - Minifig Headdress Orca with Tail and Fin with Red Eye and White Orca Marks and Teeth Pattern
has to be renamed to:
24076p02.dat - Minifig Headdress _Shark_ with Tail and Fin with Red Eye and White Orca Marks and Teeth Pattern
973p9c.dat - Minifig Torso Knit Sweater Pattern
has to be renamed to:
973p9c.dat - Minifig Torso _with_ Knit Sweater Pattern
(2020-07-15, 14:39)Willy Tschager Wrote: [ -> ]93220p04.dat - Minifig Baseball Bat with Three Metallic Silver Diamonds With Rivets Pattern
has to be renamed to:
93220p04.dat - Minifig Baseball Bat with Three Metallic Silver Diamonds _with_ Rivets Pattern
3626bp8a.dat - Minifig Head with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud with Pierced Base)
has to be renamed to:
3626bp8a.dat - Minifig Head _Female_ with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud with Pierced Base)
3626cp8a.dat - Minifig Head with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud)
has to be renamed to:
3626cp8a.dat - Minifig Head _Female_ with Peach Lips, Smile, Brown Eyebrows Pattern (Hollow Stud)
24076p02.dat - Minifig Headdress Orca with Tail and Fin with Red Eye and White Orca Marks and Teeth Pattern
has to be renamed to:
24076p02.dat - Minifig Headdress _Shark_ with Tail and Fin with Red Eye and White Orca Marks and Teeth Pattern
973p9c.dat - Minifig Torso Knit Sweater Pattern
has to be renamed to:
973p9c.dat - Minifig Torso _with_ Knit Sweater Pattern
These corrections have been made and files fast-tracked for the next release.
Why did you pick these two head prints? I see many more missing the word "Female".
I don't see why we would want to group female prints.
And there are many more prints missing the word "with". Both heads and torsos.
I pick these while I update the MLCad.ini for the Minifig generator and compare the naming of what we already have.
w.
IMHO, adding "Female" is not enough reason to recycle a part.
Especially when there is nothing shape specific in the minifig head. It gets Female when it is printed with a female pattern.
Pick the odd one out: Elf, Cuboid, Female, Spongebob, Toydarian, Yeti.
(2020-07-25, 20:29)Chris Dee Wrote: [ -> ]So do you want the _Female_ head changes removed? Probably??
If this is a vote then I vote no to adding "Female" (or "Male") to any part description (except, of course, connection types where appropriate)
(2020-07-25, 20:29)Chris Dee Wrote: [ -> ]So do you want the _Female_ head changes removed? Probably??
No, I'd like actually have added _Female_ to all heads with female attributes as it eases grouping and searching.
w.
(2020-07-26, 11:23)Willy Tschager Wrote: [ -> ]No, I'd like actually have added _Female_ to all heads with female attributes as it eases grouping and searching.
w.
Could work, but only if we place it correct in the description
IMO it should be "Minifig Head with Female (description) Pattern"
I think there are more heads missing the word "with" in the correct position, than heads missing "Female".
Shame on me.
Was so busy lately that I didn't even notice that there was a new update.
Thanks to all.
I'm not sure if this question belongs here, but still ask because the specialists are here. ;-)
When I download Windows Install.exe, in which folders are the parts installed?
(2020-08-03, 20:41)Johann Eisner Wrote: [ -> ]I'm not sure if this question belongs here, but still ask because the specialists are here. ;-)
When I download Windows Install.exe, in which folders are the parts installed?
Where did you find Install.exe ??
(2020-08-03, 20:41)Johann Eisner Wrote: [ -> ]I'm not sure if this question belongs here, but still ask because the specialists are here. ;-)
When I download Windows Install.exe, in which folders are the parts installed?
(2020-08-03, 21:10)Johann Eisner Wrote: [ -> ]Hi Chris
I mean the LDraw2001.exe from here http://www.ldraw.org/library/updates/LDraw2001.exe
Those are self extracting compressed files. They should output to "ldraw" in whatever directory they are run in.
(2020-08-03, 21:25)Orion Pobursky Wrote: [ -> ]Those are self extracting compressed files. They should output to "ldraw" in whatever directory they are run in.
?? Many Thanks.
Hi Team!
I'm a bit late to the latest parts update, but have now installed and updated colours as well. Much nicer looking MLCad.
I'm having a bit of a problem getting part 28192 to work, however. Used to work fine before the update, but now when i load projects that have included that part previously, i get the old "file not found" error, even though the correct files are in my parts and parts/s folders.
I've tried things including moving them to the Unofficial folder, deleting and re-downloading them, running mklist.exe, and scanning parts to see if i can get it to work, but so far, no luck.
I can't see it in the partslist when i try and modify a part from within MLCad either. It's like it exists, but MLCad doesn't want to know about it.
Any tips? Thanks in advance.