I just wanted to reply to http://forums.ldraw.org/showthread.php?tid=4401,4401
, but couldn't, so I am forced to post here.

I think that that voting is on a good way, but I think that the Mac users have been forgotten.
The currently suggested new text says
"it is recommended that applications understand CRLF and LF as line endings".
I think that that should be instead
"it is recommended that applications understand CRLF and LF and CR as line endings".

Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.

Quote:Line Termination

All lines in the file must use the standard DOS/Windows line termination of <CR><LF> (carriage return/line feed). The last two bytes of the file must be <CR><LF>. (In other words, there must be a <CR><LF> line terminator at the end of the last line in the file.)

Quote:Line Termination

All lines in the file must use the standard DOS/Windows line termination of <CR><LF> (carriage return/line feed). The file is permitted (but not required) to end with a <CR><LF>. It is recommended that all LDraw-compliant programs also be capable of reading files with the standard Unix line termination of <LF> (line feed).

Here is an update of my VisualLDconfig mpd, including colours defined in LDconfig.ldr update 2012-01-06.

Brickshelf folder with more renderings (after validation)

Attached Files

  visualLDconfig.mpd (Size: 384.45 KB / Downloads: 0)

Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.

Quote:Unofficial parts are allowed to be used. The filename of the unofficial part is subject to the naming rules above (e.g. 33056.dat would be renamed to <MPD Filename> - 33956.dat).

Quote:Unofficial parts are allowed to be used. The filename of the unofficial part is subject to the following naming rules:

<Set Number>[-<Optional Qualifier>] - <Unofficial Part Number>.dat

<Set Number> is the the number printed on the model's container.
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>
<Unofficial Part Number> is the unofficial part number assigned in that very moment

(e.g. 33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.dat).

Interesting read: Dissertation by Mathew Wolfe

http://www.cs.bath.ac.uk/~mdv/courses/CM...007-08.pdf

w.

I apologize for not having been able to respond to any communications sent to me. I have been called up to active duty and will be deploying to Afghanistan in June, and we have had a lot of training recently. I will attempt to post any active parts I have been working on in the hopes that someone who has the time might complete them, otherwise I'll resume working on them when I return next year. Thanks.

Phil Peickert

Looking at the old held or non-ca parts, I thought I'd tackle a group of them at once:

6162 33230 6161
and add 47115 (similar to 6162).

I noticed some discussion on stud4f4n.dat about standardizing these extra primitives, and would like to take it one step further.

Before I uploaded a bunch of new primitives, I thought I'd share my thoughts and see what others think.


The flanges on the stud4f's could extend to the meet the next flange, and additional stud4's with longer flanges could be used for edges and corners. This would reduce the file tree and number of polygons used for each rib.

Groups for single- and double-spaced stud4f's and double-spaced stud4's could be created for the standard cases (4 flanges).

Ribs and rib-groups to make up between double-spaced stud4's and edges could also be created.

I've attached a couple preliminary files to show my thoughts about the non-flush ribs and double-spaced stud groups.


None of the stud4f's are released yet, and the parts that use them aren't either.

Opinions?

Attached Files

  stug4-1x4a.dat (Size: 399 bytes / Downloads: 0)
  stug4-4x4a.dat (Size: 419 bytes / Downloads: 0)
  rib4a.dat (Size: 521 bytes / Downloads: 0)
  rib4b.dat (Size: 497 bytes / Downloads: 0)
  rig4a1x4.dat (Size: 401 bytes / Downloads: 0)

http://www.youtube.com/watch?v=AV8HP2hcXPY

https://www.youtube.com/watch?v=tyijTDuotu4

another SEOC

https://www.youtube.com/watch?v=KR3IiXvzrds


EDIT: This is not a MOC. It's a SEOC, Someone Else's Own Creation.