Hello!
I am not a programmer so I am sorry if I do not use this forum properly.
I was using Studio to make some LEGO pirate themed MOCs, but I noticed it misses some parts, that can be useful.

I read the forum rules, so I will try to post those parts properly.

MINI WIG, NO. 288 or Minifigure, Hair Combo, Hair with Hat, Long Hair with Ponytail and Molded Black Pirate Tricorne Hat Pattern

BIG PIRATE HAT or Minifigure, Headgear Hat, Pirate Circular with Fold in Brim and Marine Growth Pattern - this item exists in digital form at http://www.digital-bricks.de

Mini Wig No. 37 'no. 2' or Minifigure, Hair Female Mid-Length with Part over Front of Right Shoulder with Red Cloth Wrap / Bandana Pattern - this item exists in digital form at http://www.digital-bricks.de

Mini Wig No. 42 'no. 1' or Minifigure, Hair Long Tied Back with Black Ribbon Pattern - this item exists in digital form at http://www.digital-bricks.de

3626bpx81 - Yellow Minifigure, Head Moustache Pointed, Goatee and Stubble Pattern - Blocked Open Stud

973px135c01 - Green Torso Pirate Imperial Armada Ruffles, White Stripes Gold Medal Pattern / Green Arms / Yellow Hands

Thank you so much for your help!

Please bear with me- I am very much new to this whole thing- my 10 year old son loves to create his own Lego models and it has been his dream to create instructions to share with his friends. I’m trying to assist him, I discovered LDCAD and learned the basics in how to use it, then got him started. We got his first model completed, spent quite a bit of time refining the steps and getting it all figured out, then imported it into LPub3D to create the instructions. The first time we opened it, it was fine, then we started editing things and got the cover page looking nice. When we went further, we discovered something that needed to be fixed, so went back to LDCAD to edit that. We had both programs running, which I think was a mistake because then they kept asking if we wanted to update what the other program had changed, and I think we made the wrong choice at some point. In the process of figuring that out, we lost a bunch of edits, but then realized we needed to just run one program, do the edits and save before going to the other program to continue. Once we finished our edits in LDCAD, we went back to try and work on the instructions in LPub3D and it gives us this error- “step with INSERT COVER_PAGE meta command cannot contain type 1-5 line. Invalid type at line 31 (file:main.ldr, line:30) “. I’m at a loss on how to resolve this- I assume there’s is some piece of code that needs to be edited, but I don’t know how to get to it or what to change it to. That’s all kind of beyond my scope of understanding at this point- I am willing to learn if I can, but haven’t been able to find the right info on how to fix that. Can someone help me understand what/how to fix this? Thanks.

The 2024-10 LDraw Parts Update has been released. This update adds 390 new files to the core library, including 304 new parts and 7 new primitives.

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. This update wouldn't have been possible without their dedication and attention to detail.

You can preview the new parts in 2024-10 here, and download the zip-file update or Windows install package here.

Thank you to all the testers and parts authors who continue giving feedback on the PT software. This project would not be what it is without your help.

Orion Pobursky
LDraw.org Parts Library Admin

Does the order of the control points matter?

What is the meaning of a purple conditional line in LDPE? Most conditional lines are yellow/orange, but every once in a while even primitives have single purples here and there.

Hello, as stated here:
t04i8000-075.dat
we may need an addon for new torus prim variants...
as of now, there are only full or quarter (inside/outside) torus prims.
But sometimes we may need cut tori.
https://en.wikipedia.org/wiki/Toroidal_a...oordinates
toroidal is bigringwise (the rotation path), poloidal is smallringwise (the rotated profile)

my suggestion would be a suffix (like the -075)
and the number is the percentage of the full quarter inside/outside torus and the + or - is the direction
(from the inner/outer border or from the center line)

but you are free to discuss
(do we even need this? which way should it be done? 075 or 750? where does +/- start? and more...)

René

Hello everyone,

maybe the *.conn file format is already known but in case its not you can find the description below.  I’m also referring partly to the thread “Studio Connectivity Data“ where the question was asked how the *.conn file format is defined.

Connectivity files, e.g., the file definition is actually not too complicated to understand. However, it is more complicated as the collision files just because there are more of them and they are encrypted.

It is true that Part Designer converts the *.conn files -contrary to the *.col files- to a binary format (due to whatever reason). But this does not mean that you cannot access the information, you just have to use a trick. If you generate a part file in Part Designer and store it as *.part it contains all information about the brick. The geometry, the connectivity info and -hidden in the part geometry- the collision data. To see the connectivity info in human-readable format only thing you have to do: Start with a new part but only add connectivity elements (no geometry). In the part editor you will see an empty workspace but in the connectivity editor you can see the connectivity element. If you store this part now as *.part you can open and read it in a text editor (the conversion to binary takes places during export; not internally). From here it is rather a matter of changing the individual values/variables  in *.part file and check what are the consequences. Below an image from the STUD connectivity element e.g. the file format:

   
Figure 1.1: Connectivity file format for the STUD connectivity element (associated *.part file)

I’ve been playing around with these values and compared it with the other connectivity elements. What I’ve found out so far:

First block:              0 (always the same)
Second block:          PE_CONN (always the same, mostly likely a meta command; Part Editor Connectivity maybe)
Third block:             ID1 (group ID see figure 1.2 below)
Fourth block:           ID2 (element ID see figure 1.2 below)
Fifth block:              1 0 0 0 1 0 0 0 1 (always the same, Transformation matrix)*
Sixth block:              XYZ (Position of the element)
Seventh block:         2 2 (always the same; geometry data aka visual representation of the element)**
Eight block:             3:1,0:4,3:1,0:4,10:4,0:4,3:1,0:4,3:1 (always the same; geometry data aka visual representation of the element)***

* For other elements not always the identity matrix; see figure 1.2
** Lateral size. If you change it from 2 2 to 1 1 it has half the size. But any other value does not work
*** Most complicated one. I guess it describes or are related the geometry of the connectivity element itself (squares in the corner, disc in the center and the connection lines). If you change 10:4 to 20:4 for example the disc changes its form from a disc to a ring. Some of the numbers fit roughly to the size of the connectivity element.

One can argue that during the export Part Editor adds additional data but I’ve also checked this. I’ve generated a *.part file with connectivity elements and exported it to Studio. The associated connectivity file (*.conn) I’ve opened in Part Editor and saved it as *.part again. If the exporter from PE adds additional data to the *.conn file these files should be different but there are the same (I’m assuming PE does not remove data during import).   

In figure 1.2 you can see the *.part file with all connectivity elements you can choose from the menu. There are 43 of them. Sorted by ID1. You can see the similarity between these elements. Only the seventh and eights block is different. I guess the above file format also applies to these files (more or less).

   
Figure 1.2: Connectivity file format for all connectivity elements you can pick from task bar 

In figure 1.3 you can see all connectivity elements in the connectivity editor (sorted by group).

   
Figure 1.3: Connectivity elements in Part Designer 

Hope the helps.

Best,
Gabe

I was building some airplane MOC but there a couple of parts not found in the Studio. Is there anyone could help create those parts? Thanks heap!

5124 - Aircraft Fuselage Aft Section Bottom 6 x 8 x 4 with 4 x 6 Cargo Door Cutout, 2 Holes and 2 Pin Holes
67241pb01 - Aircraft Fuselage Forward Top Curved 8 x 12 x 6 with 6 Window Panes with Molded Trans-Light Blue Glass Pattern
92847 - Cockpit 9 x 6 x 4 1/3, Tapered with Studs on Front
67245 - Aircraft Fuselage Aft Section Curved Top 8 x 12 with 6 Holes

Hello everyone,

maybe the *.col file format is already known but in case its not you can find the description below.  I’m also referring partly to the thread “Studio Connectivity Data“ where the question was asked how the *.col file format is defined.

Collider files e. g. the file definition is actually not too complicated to understand. I’ve not checked all *.col files in the Studio LDraw folder but some of them. Hence, I cannot tell you if the file format applies to all files, but it applies to the ones I’ve checked. Below a snapshot from the collider file for brick 3005.dat (named 3005.col).

   
Figure 1.1: Collider file for brick 3005.dat (1x1 Brick)

Each line in the *.col files describes one collision box. All lines (boxes) together form kind of collider brick. Whenever two of these collider bricks are touching each other, the associated brick went transparent in Studio which indicates a collision (if the function is activated in Studio).

The file format from one collision box is as follows:

First block:                9 (always the same)
Second block:            0 (always the same)
Third block:               1 0 0 0 1 0 0 0 1 (1st part of a transformation matrix; always the same)*
Fourth block:             X Y Z (2nd part of the transformation matrix; position of the collision box)
Fifth block:                W H L (size of the collision box) 
Sixth block:               null (always the same)**

* Some of the *.col files store this block as 1 instead of 1.000
** This block only exists in the earlier *.col files (at the same time Studio beta was launched; maybe a coincidence). 

I’ve written a very simple and basic program that converts a *.col file into a *.ldr file using the box.dat primitive (one primitive for each collision box). The above file is then called 3005COL.ldr. In figure 1.2 below you can see the collider brick in red. In figure 1.3 I’ve superimposed the collider brick and the real brick itself (brick 3005 is drawn transparent for clarification).

   
Figure 1.2: Collider brick for brick 3005

   
Figure 1.3: Collider brick and brick 3005 superimposed

One can see that the collider brick is a little bit smaller as the brick itself. This can be verified with Studio also. The collision warning does not occur directly after the bricks have contact but a little later. See figure series below. 

   
Figure 1.4: Two 1x1 bricks separated. Collision warning in Studio activated. No collision detected.

   
Figure 1.5: Two 1x1 bricks just touching each other. Collision warning in Studio activated. No collision detected.

   
Figure 1.6: Two 1x1 bricks collided (they intersect a little bit). Collision warning in Studio activated. But no collision detected.

   
Figure 1.7: Two 1x1 bricks collided (they intersect a bit more). Collision warning in Studio activated. Now the bricks turn transparent to indicate a collision.

To show the geometry of more complex collider bricks, I’ve also converted the *.col files for part 10a (Baseplate 24 x 32), 64713 (Cone Spiral Jagged - Step Drill) and 59278 (Boat hull, Hull Unitary 74 x 18 x 7 with Light Bluish Gray Top). The first one is a part with multitude of studs, the second one a complex shaped part and the latter one of the largest file in the *.col folder. See images below.

   
Figure 1.8: Collider brick for part 10a.dat (Baseplate 24 x 32)

   
Figure 1.9: Collider brick for part 64713.dat (Cone Spiral Jagged - Step Drill)

   
Figure 1.10: Collider brick for part 59278.dat (Boat hull, Hull Unitary 74 x 18 x 7 with Light Bluish Gray Top)

And some close ups from 10a.dat and 59278.dat.

   
Figure 1.11: Close-up from the collider brick for part 10a.dat

   
Figure 1.12: Close-up from the collider brick for part 59278.dat

Hope the above explanation helps to get an impression how studio calculates collisions.

Best,
Gabe

i need front side maybe back top and bottom pics of sandy head id 61285
maybe fish head id 61286

Thread for Wednesday license sets