Hello,

I was wondering if someone could make this part
https://www.bricklink.com/v2/catalog/cat...5D#T=C&C=1

It would be really appreciated

Regard

I think both parts 3068bp72 and 3068bp73 have an issue.

For reference:
https://www.ldraw.org/parts/official-par...d=3068bp72
https://www.ldraw.org/parts/official-par...d=3068bp73

Backgrounds of the screen and the window of part 3068bp72 are different than those of part 3068bp73 while they should be both green and main color for the screen and Dark Blueish Grey for the window on the front like on 3068bp73. Then I think 3068bp72 needs to be modified.
Also, I could not find any photo of a real part with a Black Power Button so I'm wondering if 3068bp73 should be kept.

I don't own any version of that part myself but all photos (except of course computer generated pictures) I found for this part show actually 4 different versions with variations on the button design (either a Power Button or a simple Round Switch Button) and color (White or Dark Blueish Grey):




On that last photo I'm actually wondering if on the left side the button is Light Blueish Grey or Dark Blueish Grey...

BL references four versions:
[color=#333333][size=small][size=small][font=Tahoma, Verdana, Arial, sans-serif]Black Power Button (which for me is actually Dark Blueish Grey):[/size][/font][/size][/color]
https://www.bricklink.com/v2/catalog/catalogitem.page?P=3068bpb0062
[color=#333333][size=small][size=small][font=Tahoma, Verdana, Arial, sans-serif]Dark Blueish Grey Round Switch Button:[/size][/font][/size][/color]
https://www.bricklink.com/v2/catalog/cat...068bpb0381
White Round Switch Button:
https://www.bricklink.com/v2/catalog/cat...068bpb0851
White Power Button:
https://www.bricklink.com/v2/catalog/cat...068bpb0058

Any thoughts?

Note: I directly copied this from Roland's post.

Please vote for the following update to the MPD spec that allows for binary data to be included in an MPD file.

----------------------

Purpose
MPD files or "Multi-Part Documents" are a way to combine several LDraw and encoded binary files into one consolidated source. This allows for ease in posting or emailing a model made up of many subparts.

Structure
A MPD file consists out of blocks of LDraw code separated by 0 FILE or 0 !DATA statements. Each block is considered a separate file and can be referenced by the other ones as needed.

Blocks starting with the 0 FILE statement are normal type 0..5 line LDraw code.

Blocks starting with the 0 !DATA statement contain binary data encoded using a multitude of 0 !: lines. Each of those lines contain a chunk of base64 encoded data which a parser must combine before decoding. No other LDraw statements may be used inside a !DATA block.

The end of each block, or just the last block in the MPD, may be marked with a 0 NOFILE line. The 0 NOFILE command is only required if the file's contents are followed by non-LDraw content (such as the poster's signature lines). LDraw parsers must then ignore all content until a new 0 FILE or 0 !DATA is found.

In order to support the inclusion of MPD files in message systems (like email), any text lines before the first 0 FILE or 0 !DATA statement will be discarded. It is considered to be an error for any LDraw code (other than comment lines) to appear before the first 0 FILE or 0 !DATA statement.

The first block in the MPD is treated as the 'main model' -- all other files in the MPD will only be rendered if they are referenced by the main model, directly or indirectly. For this reason it is recommended (but not required) to always use a 0 FILE block as the first entry in the MPD.

So far, there are no clear scoping or namespace rules on MPD files. If you put a file named stud.dat in your MPD file, don't be surprised to see your stud.dat file appear on the top of every single brick in your scene.

MPD META Statements

FILE
Format: 0 FILE <filename>
Where:
<filename> is the name of the following LDraw file.

!DATA
Format: 0 !DATA <filename>
Where:
<filename> is the filename of the following encoded data.

!:
Format: 0 !: <base64 string>
Where:
<base64 string> is a chunk of the base64 encoded data (A-Za-z0-9+/) with a maximum length of 80 characters (60 bytes of data). Each line except the last should use the same length and be a multiple of 4 characters. Padding the last line with '=' characters to complete its last group of 4 is optional.

NOFILE
Format: 0 NOFILE
There are no options or parameters.

Example

I'm starting to think we have a documentation fragmentation problem. There are simply too many places to look for requirements, especially for parts authoring. What I'm not sure about is if this is a presentation problem or that we need to start consolidating documents. Thoughts?

We already have unofficial control bricks, such as the SBrick in the parts tracker: https://forums.ldraw.org/thread-15582.html

I would like to include PFx parts in the similar fashion. These parts have already been created: https://github.com/fx-bricks/pfx-ldraw-m...ster/ldraw

However. There are some issues:

• Some of the authored parts have been created using a conversion tool that makes way too many polygons and cause rendering issues due to polygon orientation and other artefacts. These will have to be rebuilt manually. I am fine with taking up this task, unless someone else has already done so.
  
• The license of the already-authored parts is not compatible with the one we use. Once the parts have been rebuilt, I think there should be a pull request raised to the original author, so that the new part files can be shared.
  
• In order to ensure backward-compatibility with the existing parts, the origin of those should be preserved. Will this be an issue in case they do not follow our standard?
  
• The naming of their parts do not follow our standard: The names are too long, causing issues in some of our older software, and they use CamelCase naming, which is information that isn't preserved when we ignore case.
  
• The studs and anti-studs are square. Do we have square studs and anti-studs in the library with connection information? Otherwise this might cause issues in LDCad, et. al.
  

I used "SoildWorks" to make the part, save it as "STL", and then use "slt2dat.exe"Switching to various styles, and then using" PartDesigner "to open, but I encountered 2 problems:
1. After opening, the part defaults to down instead of up;
2. Strange lines appear;



[img] https://mini-p.oss-cn-shanghai.aliyuncs....281%29.jpg[/img]

I'd like to update my MOC in Studio to use some better parts that aren't available there yet. Among them are the two jester torsos from the castle line: red and blue, and red and white. The Bricklink item numbers for the complete assemblies are:

973pb0514c01
973pb0675c01

It's been a long time since I dabbled in torso design so it'd take a lot for me to dust off that skillset. Anyone else up tot he challenge?

Hi everyone!

I see 60642c03pr0001 and 60639c03pr0001 do not exist yet on LDraw. Is someone interested in creating these parts?

60642c03pr0001

Hi everyone!

I see 60674 does not exist yet on LDraw. Is someone interested in creating this part? I did turn the side view photos left on its axis.


60674














If there are any questions, ask me. 

Hi everyone!

I see 60671pr0004 do not exist yet on LDraw. Is someone interested in creating this part? The hole for the arm goes all the way trough the other side.

60671pr0004














The horns do not go all the way in.

If there are any questions, feel free to ask me anything.