The following was posted by Willy Tschager in the Standards Board forum. In my opinion, that was not the right place for it, so I am starting a thread here.

(2021-08-13, 11:18)Willy Tschager Wrote: Guys,

in response to this post:

https://forums.ldraw.org/thread-24732.html

the majority of the SteerCo is in favour to add helper parts to the library but before a final vote we would like you to define a standard for these parts such as:

Naming convention
Category
Edges Yes/No on 2D helpers
Edges Yes/No on 3D helpers

The general idea would be to add these to the main library as the separate Alias and Physical parts library hasn't worked very well. In addition these parts shouldn't go through the PT for certification but be usable in all editors. Any input from your side is welcome.

Some example of helpers can be found here:

http://www.holly-wood.it/ldraw/helper-en.html

w.

Hi, I was creating instructions with LPub3D when I encountered this bug.

The torus subpart of https://www.ldraw.org/parts/official-par...rtid=49098 isn't rendered.

I investigate a bit and notice there's no consistency in this bug. Even here on LDraw.org.
Coming next are screenshots of this part as viewed by several softwares :

in the part tracker :
- this one is a 200% view of the PT's thumbnails (maybe generated with LDView ?)


- this one is from the PT's 3D viewer, part is complete, yay !

- in LDView, note that the tree info module shows the primitive and knows that the quads should be rendered (red highlight) :

- in MLCad (the old man knows how do deal with parts) :

- LDCad  (BFC is working here) :


- LPub3D 200% PLI display unsing LDView (since LDView doesn't render the part correctly, it's obvious this one isn't correct) :

- LPub3D with the native rendering engine (works fine) :


- Last but not least, I inlined the torus primitive and "ta-da !" :

LDView finaly rendered the file nicely.

I can't remember when, but it's a bypass I allready used this year and that we discussed here. I used (maybe badly) the search option of the forum and didn't find the thread.

EDIT : The problem still exists in LPub3D

Greetings.

I've just stumbled across what I think is a small bug in LDCad. Since there's a 1.7 version in the works, now's as good a time as any to have found it!

For parts that are far away from the origin (more than 1000LDU), if I open the Reference/selection properties box to put in new coordinates, the numbers/s are displayed with commas as thousands separators. But when I hit Accept to dismiss that box, that comma gets interpreted as a decimal point, and my part moves much closer to the origin - from x=1020 (say) to x=1.02.
Have I described that well enough? Feel free to ask any clarifying questions.

I'm using LDCad 1.6d (LNX64). I don't think I've done anything special with my system localisation settings.

Apologies if this is a known bug, I couldn't find anything on the website or the release notes.

Thanks again for a great product.

Owen.

Hi

Can anyone please make this part for me?

2431pb534
As soon as possible please

Hi

Can anyone please make this part for me?
2431pb580
As soon as possible please

I'm a non-English speaking person, so I may not be able to speak well.
I'll do my best.

I'm going to use LDraw to create an animation and upload it to YouTube.

In this case, should I hide the LEGO logo on the brick studs?

My buddy Dave @ BrickNerd asked me to request the following two parts:

• 41927 - Human Tool Dots Bag Tag Cube - https://www.bricklink.com/v2/catalog/cat...ge?P=69182
  
• 73767 - Human Tool Dots Bag Tag Ring - https://www.bricklink.com/v2/catalog/cat...ge?P=73767
  

I'm just starting with LDCad, and so far I'm loving. But I'm having trouble trying to manage groups. I can create them and move them and rotate them, but when I want to group together sub groups, then things get messy. Once I group groups together, I can no longer find a way to select the sub groups. All that I can select is the main top-level group. If I remove the top level group, then I can access the individual groups again. However, I can no longer access the top level group unless I regroup all the groups again. This is not ideal especially when working with large models. Also, if I hover over a group, I can see in the bottom a group name like "Group 1" etc... but cannot find where I can edit that to name the groups. Surely, I must be doing something wrong?

Can someone help me figure out how to manage all these groups?

P.S I know about Group Layers, but this isn't what I'm looking for. If I group together a bunch of groups, I should be able to move / rotate that top level group, then also be able to select a sub group from a list or tree and rotate just that part too. Is there a way to do that?

Thanks!

Guys,

in response to this post:

https://forums.ldraw.org/thread-24732.html

the majority of the SteerCo is in favour to add helper parts to the library but before a final vote we would like you to define a standard for these parts such as:

Naming convention
Category
Edges Yes/No on 2D helpers
Edges Yes/No on 3D helpers

The general idea would be to add these to the main library as the separate Alias and Physical parts library hasn't worked very well. In addition these parts shouldn't go through the PT for certification but be usable in all editors. Any input from your side is welcome.

Some example of helpers can be found here:

http://www.holly-wood.it/ldraw/helper-en.html

w.

Hello,I was repairing my crappy 15068px0  when I noticed that there are gaps in this part.

The subfiles don't match at the vertices 20 -4 -20, -20 -4 -20, -20 -16 20 and 20 -16 20 (aka the top corners) the 48\1-8cyli.dat don't match the s01, and inside the s01, the 48\1-8chrd.dat don't match the top corner either.

1 1 -20 24.9719 20 0 1 0 -40.97 0 0 0 0 -56.57 48\1-8chrd.dat
1 2 20 25 20 0 -1 0 -40.97 0 0 0 0 -56.57 48\1-8chrd.dat
1 4 20 24.972 20 0 -40 0 -28.9719 0 -28.9719 -40 0 40 48\1-8cyli.dat

I didn't check all the printed parts, but the problem is present on p01 for instance.

Should this part been reworked or should it be left like that ?