LDraw.org 2017-01 Parts Update Now Available

[Chris Dee]

The 2017-01 LDraw Parts Update has been now been released. This adds 717 new files to the core library, including 509 new parts and 33 new primitives. This update also includes updated versions of the colour configuration files (LDConfig.ldr and LDCfgalt.ldr) thanks to Willy Tschager and Magnus Forsberg.

Thanks are of course due to all the part authors who created or corrected parts for this release, including several first-time authors. The 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 2017-01 here, 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.

[Max Martin Richter]

And special thanks to our library admin. He did a great work again! Thanks Chris!

/Max

[Richard Speyer]

Thanks everyone for all your hard work.

[Philippe Hurbain]

Can't say better

[Magnus Forsberg]

Thank you all

[Santeri Piippo]

Congratulations everyone!

[Nils Schmidt]

Thanks everyone involved! :)

[Johann Eisner]

Thanks and Congratulations everyone! 
I'm happy, to be a little brick of this big building.

[Willy Tschager]

Thanks to all authors and reviewer and a special thank you to the JJMA recipient 2017.

w.

[Travis Cobbs]

It looks like a UTF-8 Byte Order Mark (BOM) was added to ldconfig.ldr, which causes an error to show up any time any model is loaded in LDView (although the error doesn't otherwise hurt anything). I'll see about getting LDView to ignore UTF-8 BOMs in all files, but given the infrequency at which LDView released, it could be a while before this fix is released. LDCfgalt.ldr doesn't appear to have a BOM.

[Roland Melkert]

It looks like a UTF-8 Byte Order Mark (BOM) was added to ldconfig.ldr, which causes an error to show up any time any model is loaded in LDView (although the error doesn't otherwise hurt anything). I'll see about getting LDView to ignore UTF-8 BOMs in all files, but given the infrequency at which LDView released, it could be a while before this fix is released. LDCfgalt.ldr doesn't appear to have a BOM.

Notepad has the nasty habit of adding a bom if there are actual unicode characters in a file.

[Orion Pobursky]

It looks like a UTF-8 Byte Order Mark (BOM) was added to ldconfig.ldr, which causes an error to show up any time any model is loaded in LDView (although the error doesn't otherwise hurt anything). I'll see about getting LDView to ignore UTF-8 BOMs in all files, but given the infrequency at which LDView released, it could be a while before this fix is released. LDCfgalt.ldr doesn't appear to have a BOM.

Notepad has the nasty habit of adding a bom if there are actual unicode characters in a file.

By spec, we should have any Unicode in any compliant files

[Travis Cobbs]

By spec, we should have any Unicode in any compliant files

Two things. First of all, the only non-ASCII characters I can find in the file are the three bytes of the UTF-8 BOM.

Secondly, all valid UTF-8-encoded Unicode characters are allowed in all LDraw files (including official library files). The current file format spec does forbid the BOM, but it explicitly states that all LDraw files must be UTF-8. The official library restrictions spec makes no mention of ASCII or UTF-8. So, since LDraw files are defined to be UTF-8, and the restrictions document doesn't require them to be pure ASCII, they are fully UTF-8.

[Orion Pobursky]

By spec, we should have any Unicode in any compliant files

Two things. First of all, the only non-ASCII characters I can find in the file are the three bytes of the UTF-8 BOM.

Secondly, all valid UTF-8-encoded Unicode characters are allowed in all LDraw files (including official library files). The current file format spec does forbid the BOM, but it explicitly states that all LDraw files must be UTF-8. The official library restrictions spec makes no mention of ASCII or UTF-8. So, since LDraw files are defined to be UTF-8, and the restrictions document doesn't require them to be pure ASCII, they are fully UTF-8.

You're right. I brain farted that we changed the spec.

[Travis Cobbs]

Now that some of Philo's texture-mapped parts are official, they are no longer on the parts tracker, so the URL to their texture (listed on the tracker when they were posted) has been lost. Is there some place we can record those URLs while the official library itself doesn't include the textures?

[Willy Tschager]

Working on the MLCad.ini I came across the following:

u9332.dat - Minifig Arm Curved with Hand

should IMHO be renamed to

Minifig Arm, Short, Curved with Hand


95330p01.dat - Minifig Axe With Red Head and Silver Blade Pattern

should IMHO be corrected to

95330p01.dat - Minifig Axe with Red Head and Silver Blade Pattern

w.

[Chris Dee]

Now that some of Philo's texture-mapped parts are official, they are no longer on the parts tracker, so the URL to their texture (listed on the tracker when they were posted) has been lost. Is there some place we can record those URLs while the official library itself doesn't include the textures?

The Parts Tracker comment history is archived, so although the is no way to display it, I can provide those URLs.

The only ones I could find were:
parts/19204p01.dat: Looks MUCH better with the texture file available here... http://www.brickshelf.com/gallery/Philo/...204p01.png
parts/3960p0b.dat: Texture file available here: http://www.brickshelf.com/gallery/Philo/...960p0b.png

...and yes, I should find some time to add TEXMAP support to the Parts Tracker.

[Willy Tschager]

It looks like a UTF-8 Byte Order Mark (BOM) was added to ldconfig.ldr, which causes an error to show up any time any model is loaded in LDView (although the error doesn't otherwise hurt anything). I'll see about getting LDView to ignore UTF-8 BOMs in all files, but given the infrequency at which LDView released, it could be a while before this fix is released. LDCfgalt.ldr doesn't appear to have a BOM.

I edit the LDConfig with LibreOffice and save as .txt. Anything I can do?

w.

[Chris Dee]

It looks like a UTF-8 Byte Order Mark (BOM) was added to ldconfig.ldr, which causes an error to show up any time any model is loaded in LDView (although the error doesn't otherwise hurt anything). I'll see about getting LDView to ignore UTF-8 BOMs in all files, but given the infrequency at which LDView released, it could be a while before this fix is released. LDCfgalt.ldr doesn't appear to have a BOM.

I edit the LDConfig with LibreOffice and save as .txt. Anything I can do?

w.

I think I introduced this in converting the file Willy supplied from UNIX line-endings to DOS line-endings. The version on the server at ldconfig.ldr is fixed (thanks Steffen). It looks like I need to do an emergency mini-release to fix this and other minor glitches in 2017-01.

[Chris Dee]

Working on the MLCad.ini I came across the following:

u9332.dat - Minifig Arm Curved with Hand

should IMHO be renamed to

Minifig Arm, Short, Curved with Hand


95330p01.dat - Minifig Axe With Red Head and Silver Blade Pattern

should IMHO be corrected to

95330p01.dat - Minifig Axe with Red Head and Silver Blade Pattern

w.

Both fast-tracked for the next update.

[Steffen]

I think we should release the texture images
together with the parts.

I suggest putting them into a new folder next to /p and /parts
called /textures

[Travis Cobbs]

I think we should release the texture images
together with the parts.

I suggest putting them into a new folder next to /p and /parts
called /textures

Actually, they won't work there (based on the !TEXMAP spec that allows them to work). They have to go into parts/textures (or p/textures if there are textured primitives).

[Willy Tschager]

Since I don't have this part could someone please check if the short handle of the Lifeguard Float can be gripped by a minifig hand?

   

In the version we have there is an overlap:

1 47 0 39 -19 1 0 0 0 0.97 0.242 0 -0.242 0.97 3820.dat
1 4 0 35 -28 0 1 0 1 0 0 0 0 -1 90395.dat

Thx, w.

[Willy Tschager]

Minifig Mechanical Head with Yellow Insignia Pattern

should be renamed to:

Mechanical Head SW Battle Droid with Yellow Insignia Pattern

to be in sync with 30378 - Minifig Mechanical Head SW Battle Droid


There is inconsistenty in the Lightsaber naming (Tool, Lightsabre, Light Sabre):

[b]577bc01.dat - Minifig Lightsaber Chrome Silver - 1 Side On
61199.dat - Minifig Lightsaber Hilt Short Curved
42114.dat - Minifig Tool Light Sabre Hilt with Bend
42114c01.dat - Minifig Tool Lightsaber with Bend Chrome Silver - 1 Side On
42114c02.dat - Minifig Tool Lightsaber with Bend Chrome Silver - 2 Sides On

w.

[Chris Dee]

Minifig Mechanical Head with Yellow Insignia Pattern

should be renamed to:

Mechanical Head SW Battle Droid with Yellow Insignia Pattern

to be in sync with 30378 - Minifig Mechanical Head SW Battle Droid


There is inconsistenty in the Lightsaber naming (Tool, Lightsabre, Light Sabre):

[b]577bc01.dat - Minifig Lightsaber Chrome Silver - 1 Side On
61199.dat - Minifig Lightsaber Hilt Short Curved
42114.dat - Minifig Tool Light Sabre Hilt with Bend
42114c01.dat - Minifig Tool Lightsaber with Bend Chrome Silver - 1 Side On
42114c02.dat - Minifig Tool Lightsaber with Bend Chrome Silver - 2 Sides On

w.
[/b]

42114.dat had already been fast-tracked through the Parts Tracker to standarise the spelling of Lightsaber. Are you suggesting that we remove the word 'tool'?

Description for 30378ps1.dat, 30378ps2.dat and 30378ps3.dat updated and fast-tracked through the Parts Tracker.

[Willy Tschager]

42114.dat had already been fast-tracked through the Parts Tracker to standarise the spelling of Lightsaber. Are you suggesting that we remove the word 'tool'?

Description for 30378ps1.dat, 30378ps2.dat and  30378ps3.dat updated and fast-tracked through the Parts Tracker.

Well, it can be used as a flame cutter but rather then a tool this is primarily a weapon, so yes, removing tool makes sense.

w.

[Philippe Hurbain]

Since I don't have this part could someone please check if the short handle of the Lifeguard Float can be gripped by a minifig hand?

Don't have it either, geometry comes from LDD. Considering the small overlap, could also be LDraw hand geometry that's slightly wrong...

[Gerald Lasser]

Since I don't have this part could someone please check if the short handle of the Lifeguard Float can be gripped by a minifig hand?

Don't have it either, geometry comes from LDD. Considering the small overlap, could also be LDraw hand geometry that's slightly wrong...

I've got the part (and a Minifg ) Let you kown in the evening

[Willy Tschager]

I'm through with the MLCad.ini and suggest on more change:

Rename:

973pbp.dat - Minifig Torso with Spider-Girl Pattern

to

973pbp.dat - Minifig Torso with Spider Girl Pattern

to be in sync with:


973pbv.dat - Minifig Torso with Spider Man Pattern

w.

[Gerald Lasser]

Don't have it either, geometry comes from LDD. Considering the small overlap, could also be LDraw hand geometry that's slightly wrong...

I've got the part (and a Minifg ) Let you kown in the evening

Results of my measurement, overall dimensions are pretty much ok, below 0,5 to 0,25 LDU

The handle is now 11,5 LDU, the real parts is 4,8 mm = 12 LDU, so it is off by 0,5 LDU

The minifig hand is now 12 LDU, the real part is 4,5 mm = 11,25 LDU

The real hand fits on the real part with a small gap

-> Moving the vertices 0,25 LDU outside on the op and bottom seems to be the solution that it the least intrusive and still does not distort the part.

[Magnus Forsberg]

Since I don't have this part could someone please check if the short handle of the Lifeguard Float can be gripped by a minifig hand?

Yes, a minifig hand can grip the short handle. I meassure the hand to 4.5mm and the grip to 4.8

In 90395.dat the handle is 11.5 LDU (4.6mm)
In 3820.dat the hand is 12 LDU (5mm)

[Steffen]

Hello Chris,

I just noticed that 2 files were missing in the 2017-01 parts update:

http://www.ldraw.org/cgi-bin/ptdetail.cg...u22s2e.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...tu22s2.dat

They cause the error that MLCad displays an error message popup
as soon as it tries to generate a thumbnail in its parts list for the parts

13349.dat
18759.dat
22889.dat
24201.dat
32803.dat
4287b.dat
4287c.dat
60219.dat
72454.dat
89801.dat

I suggest to include these 2 files in the next parts update to cure this problem.

The problem can only be noticed when you use a clean install of complete.zip (2017-01) with MLCad, without adding the unofficial files
mentioned above from the PT.

best
Steffen

[Steffen]

I just noticed that the file 98138pm5.dat contained in update 2017-01 makes MLCad crash as soon as it tries to create a thumbnail for it.

The reason is the syntax error

Code:

0 BFC NO CLIP

in that file.
That statement anyway should not be there IMHO.
I have sent the corrected file to Chris.

That file should be included in the next parts update to prevent the MLCad crash IMHO.

I systematically checked the full update 2017-01 for similar errors.
When this error and the one above (post #32) are cured, all MLCad thumbnails can be generated fine.

[Willy Tschager]

Is anybody working on this part?

w.

[Philippe Hurbain]

Is anybody working on this part?

No, but I could, just ask gently ;D

[Willy Tschager]

Is anybody working on this part?

No, but I could, just ask gently ;D

Philo,

would you mind doing me a personal favour and please, please fix this part. I beg you - on my knees.

w.

[Philippe Hurbain]

would you mind doing me a personal favour and please, please fix this part. I beg you - on my knees.

Seems enough
Modified part sent to Chris. Not really convinced it was necessary, but...

[Chris Dee]

Hello Chris,

I just noticed that 2 files were missing in the 2017-01 parts update:

http://www.ldraw.org/cgi-bin/ptdetail.cg...u22s2e.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...tu22s2.dat

They cause the error that MLCad displays an error message popup
as soon as it tries to generate a thumbnail in its parts list for the parts

13349.dat
18759.dat
22889.dat
24201.dat
32803.dat
4287b.dat
4287c.dat
60219.dat
72454.dat
89801.dat

I suggest to include these 2 files in the next parts update to cure this problem.

The problem can only be noticed when you use a clean install of complete.zip (2017-01) with MLCad, without adding the unofficial files
mentioned above from the PT.

best
Steffen

Corrected in 2018-01.

[Chris Dee]

I just noticed that the file 98138pm5.dat contained in update 2017-01 makes MLCad crash as soon as it tries to create a thumbnail for it.

The reason is the syntax error

Code:

0 BFC NO CLIP

in that file.
That statement anyway should not be there IMHO.
I have sent the corrected file to Chris.

That file should be included in the next parts update to prevent the MLCad crash IMHO.

I systematically checked the full update 2017-01 for similar errors.
When this error and the one above (post #32) are cured, all MLCad thumbnails can be generated fine.

Corrected in 2018-01.

[Chris Dee]

42114.dat had already been fast-tracked through the Parts Tracker to standarise the spelling of Lightsaber. Are you suggesting that we remove the word 'tool'?

Description for 30378ps1.dat, 30378ps2.dat and  30378ps3.dat updated and fast-tracked through the Parts Tracker.

Well, it can be used as a flame cutter but rather then a tool this is primarily a weapon, so yes, removing tool makes sense.

w.

Descriptions updated, removing 'Tool' from 42114, 42114c01 and 42114c02 and fast-tracked through the Parts Tracker.