From Willy: Define a standard for helper parts

[Travis Cobbs]

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.

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.

[Travis Cobbs]

Since I don't really build LDraw models (with or without instructions), I don't really feel qualified to debate over how these should look. Having said that, my first thoughts would be:

Not sure about naming convention.
Category: Helper
Edges on 3D helpers.
No Edges on 2D helpers.

I feel that the community at large should give their thoughts, and once some kind of consensus has been reached, the standards board can vote on it.

[Milan Vančura]

Since I don't really build LDraw models (with or without instructions), I don't really feel qualified to debate over how these should look. Having said that, my first thoughts would be:

Not sure about naming convention.
Category: Helper
Edges on 3D helpers.
No Edges on 2D helpers.

I feel that the community at large should give their thoughts, and once some kind of consensus has been reached, the standards board can vote on it.

This is very good message SteerCo agrees with helpers addition. I agree with Travis about Category and edges. Plus I'd add a rule about BFC for 2D helpers so no "one side visible" helpers are accepted.

I'm not sure about naming convention as I'm not on any board and I don't know all details behind this. From my POV, the most important two points about naming are: make it clear and make it expandable in future. For this reason I suggest "Helper Arrow " as a prefix for arrows I suggested in the original thread. For example: "Helper Arrow Straight 3L". In future, it may be that we add another type of helper than arrows and with this scheme no conflict appears.

For the same reason, I'd add KEYWORDS: Helper, Arrow  for these arrows.

On the other side, for filenames (part "codes"), I think a simple scheme like "h" prefix and a number is enough. For example h0001.dat - the number does not need to code anything, it's same as for any other part categories, the number is absolutely independent on anything else like a part category or subcategory. Maybe in future we can add helpers with a pattern, like h0001bp01.dat , but since then, I'd simply number helpers as they come: h0001, h002...

[Willy Tschager]

Category: Helper
Edges on 3D helpers.
No Edges on 2D helpers.

I'm fine with you letting the community decide. My suggestion would be:

Description: |Helper (Arrow 2D Straight, Arrow 3D Rotation, Dots xx, Line, Number 3D "1", Letter 2D "G", Letter 3D "f"...) as for the third party parts it starts with '|' or '~|' (as appropriate)
Name:
Category: Not needed with "Helper" in the description
Edges on 3D Helpers
No Edges on 2D Helpers

w.

[Orion Pobursky]

I'm fine with you letting the community decide. My suggestion would be:

Description: |Helper (Arrow 2D Straight, Arrow 3D Rotation, Dots xx, Line, Number 3D "1", Letter 2D "G", Letter 3D "f"...) as for the third party parts it starts with '|' or '~|' (as appropriate)
Name:
Category: Not needed with "Helper" in the description
Edges on 3D Helpers
No Edges on 2D Helpers

w.

I agree with this.

My only desired is that I do not want these parts subject to normal PT review. These are not LEGO parts and do not need to held to that standard.

[Travis Cobbs]

I agree with this.

My only desired is that I do not want these parts subject to normal PT review. These are not LEGO parts and do not need to held to that standard.

Should the filenames perhaps reflect the fact that these aren't LEGO parts? In other words, even though these are in the parts directory, is there any particular reason that the filenames should be predominantly numbers? Or should we instead include somewhat descriptive filenames?

[Jaco van der Molen]

I am using the original Helper parts from Willy for years now.
It would be fine for me if we implement them like he made and named them and distribute with the library.

[Milan Vančura]

Should the filenames perhaps reflect the fact that these aren't LEGO parts? In other words, even though these are in the parts directory, is there any particular reason that the filenames should be predominantly numbers? Or should we instead include somewhat descriptive filenames?

I think the description should go into Description tag. Filename should be short and easy to add any new one. My experience is that attempts putting some meaning into a filename make a confusion later: unreadable abbreviations used, discussions about adding some new unexpected type of helper in future and so on.

I suggested a scheme h<number>.dat not to mimic official parts (or even worse, to confuse anybody these are official parts), I suggested it because it is simple and working in 2021, 2167, everything in between and even after

Just my explanation. Nothing more.

[Willy Tschager]

I'm fine with you letting the community decide. My suggestion would be:

Description: |Helper (Arrow 2D Straight, Arrow 3D Rotation, Dots xx, Line, Number 3D "1", Letter 2D "G", Letter 3D "f"...) as for the third party parts it starts with '|' or '~|' (as appropriate)
Name:
Category: Not needed with "Helper" in the description
Edges on 3D Helpers
No Edges on 2D Helpers

w.

Thinking about I would put the 2D/3D qualifier right after "Helper":

|Helper 2D Arrow
|Helper 2D Letter "w"
|Helper 3D Arrow Straight 2L
|Helper 3D Easy Rotation
|Helper 3D PovRay Light
|Helper 3D LSynth Constraint Part - Type 1 - "Hose"

As for the name how about a mix of name and consecutive number:

Helper0001.dat
Helper0002.dat
...
Helper9999.dat

w.

[Willy Tschager]

My only desired is that I do not want these parts subject to normal PT review. These are not LEGO parts and do not need to held to that standard.

I'm fine with this but I'd like to see no regular submission by the user to the PT but proxy/fast-track by the PT admin. At least that will guarantee the naming is correct.

However to get a some sort of standard I suggest that at least numbers and letters should fit into a grid, say have the height of a Brick 1x1 or 2x2 ... hmm this calls for a scaling tool in the editors as the casual user is not able to work on the matrix. Wait, maybe he is:

http://www.holly-wood.it/mlcad/advanced4...ml#scaling

but a scaling tool would be awesome anyway.

w.

[Milan Vančura]

Thinking about I would put the 2D/3D qualifier right after "Helper":

|Helper 2D Arrow
|Helper 2D Letter "w"
|Helper 3D Arrow Straight 2L
|Helper 3D Easy Rotation
|Helper 3D PovRay Light
|Helper 3D LSynth Constraint Part - Type 1 - "Hose"

As for the name how about a mix of name and consecutive number:

Helper0001.dat
Helper0002.dat
...
Helper9999.dat

w.

Nice idea. I agree both with Descriptions and names.
Plus, I'd add CATEGORY (Helper) because why make those parts "homeless" if we know where they belong to? And we can use this information easily later. For example the definition of an editor part bin "CATEGORY == Helper" is easier than by "Helper" in descriptions, preceded by "|", "~|" or nothing (which needs regular expressions or so).

[Chris Dee]

I'm fine with this but I'd like to see no regular submission by the user to the PT but proxy/fast-track by the PT admin. At least that will guarantee the naming is correct.

However to get a some sort of standard I suggest that at least numbers and letters should fit into a grid, say have the height of a Brick 1x1 or 2x2 ... hmm this calls for a scaling tool in the editors as the casual user is not able to work on the matrix. Wait, maybe he is:

http://www.holly-wood.it/mlcad/advanced4...ml#scaling

but a scaling tool would be awesome anyway.

w.

Yes, for ease of packaging into  Parts Update these should go through the Parts Tracker, but I don't have a problem with doing proxy submit and fast-track.

[Travis Cobbs]

Plus, I'd add CATEGORY (Helper) because why make those parts "homeless" if we know where they belong to? And we can use this information easily later. For example the definition of an editor part bin "CATEGORY == Helper" is easier than by "Helper" in descriptions, preceded by "|", "~|" or nothing (which needs regular expressions or so).

From the !CATEGORY and !KEYWORDS spec:

If a part has no !CATEGORY meta-statement, the category is assumed to be the first word in the part name (ie. the first word of the first line of the part file).

There should be no need for an explicit !CATEGORY meta-statment based on the proposed names. It will automatically be in the Helper category. I don't use LDCad, but hopefully it already correctly implements this behavior. If CATEGORY == <Whatever> does not work in LDCad for parts without an explicit !CATEGORY meta-statement, then I would suggest requesting that LDCad be fixed.

[Willy Tschager]

Should the filenames perhaps reflect the fact that these aren't LEGO parts? In other words, even though these are in the parts directory, is there any particular reason that the filenames should be predominantly numbers? Or should we instead include somewhat descriptive filenames?

As the current Helper have to reworked anyway using the description also as name such as:

Helper3DEasyRotation.dat

would indeed add some value.

w.

[Orion Pobursky]

I started a page to track our discussions about the spec with the intent of having a fully formed proposal for the LSB to vote on when we are done.
https://www.ldraw.org/draft-documents/helper-parts.html

[Roland Melkert]

No Edges on 2D helpers.

Why forbid that, Isn't it up to the 'style' of the (e.g.) arrow collection to include edges or not.

As for the naming it might be an idea to put them in a new subfolder (along side parts and p), e.g. 'helper' and reference them in models like "helper\blabla.dat"

[Milan Vančura]

There should be no need for an explicit !CATEGORY meta-statment based on the proposed names. It will automatically be in the Helper category. I don't use LDCad, but hopefully it already correctly implements this behavior. If CATEGORY == <Whatever> does not work in LDCad for parts without an explicit !CATEGORY meta-statement, then I would suggest requesting that LDCad be fixed.

About LDCAD: I don't know, I'm not the author... I thought it generally (as having some years of experience with databases): if some meta information is static in time, it's always a benefit to mention it clearly as an extra field, for practical reasons. Just my 2 cents for this brainstorming.

[Milan Vančura]

Why forbid that, Isn't it up to the 'style' of the (e.g.) arrow collection to include edges or not.

This is an interesting point. What about this rule instead: "Edges must be always in the edge color. If the author's idea is to have them in the main color, they (edges) should be omit instead."

[Willy Tschager]

As for the naming it might be an idea to put them in a new subfolder (along side parts and p), e.g. 'helper' and reference them in models like "helper\blabla.dat"

+1

w.

[Willy Tschager]

Why forbid that, Isn't it up to the 'style' of the (e.g.) arrow collection to include edges or not.

It's difficult discussing about taste but I would say to differenciate a 2D helper from 3D and to be in line with "very" flat parts such as sticker.

w.

[Roland Melkert]

About LDCAD: I don't know, I'm not the author... I thought it generally (as having some years of experience with databases): if some meta information is static in time, it's always a benefit to mention it clearly as an extra field, for practical reasons. Just my 2 cents for this brainstorming.

LDCad will use the first word (without ~_|) in the description if (and only if) there is no !CATEGORY one.

Once determined there is no difference between a !CATEGORY or 1st word one internally, so it should handle like it was read from !CATEGORY ether way.

[Roland Melkert]

As for the naming it might be an idea to put them in a new subfolder (along side parts and p), e.g. 'helper' and reference them in models like "helper\blabla.dat"

Correction:
I mean a new folder besides the "s" one in parts, unless we want to extend the p and parts search location order to inlcude the new "helper" one (which won't be backwards compatible in most programs).

And maybe shorten it to just "h" to be more like the existing "s"

[Willy Tschager]

As the discussion has died down I made a summary of where the LSB has to agree upon:

Naming convention:

• Scheme: h<number>.dat
  
• Scheme: Helper<number>.dat
  
• Name as description without blanks: Helper3DEasyRotation.dat
  

Description:

As for the third party parts it starts with '|' or '~|'

• |Helper <2D/3D qualifier> <Type> <additional description> <lenght/height/depth>
  

<Type> Arrow, Dot, Line, Letter, Number, Light, LSynth Constraint, String Knot ...
<additional description> Straight, Rotation, "3", "F", Vertical
<lenght/height/depth> 2L, 3 Studs, 20 LDU, 10 mm

Note: It has to be decided if it is "Helpers" or "Helper".

Category:

Not needed. From the !CATEGORY and !KEYWORDS spec: If a part has no !CATEGORY meta-statement, the category is assumed to be the first word in the part name (ie. the first word of the first line of the part file).

Location:

• LDraw root LDraw\helpers
  
• Parts folder LDraw\parts
  
• Subfolder LDraw\parts\helpers
  
• Subfolder LDraw\parts\h
  

Note: It has to be decided if it is "helpers" or "helper".

Design:

• No edges on 2D helpers as for stickers
  
• Edges on 2D helpers as for parts
  
• Edges Yes/No on 2D helpers - leave the final decision to the author
  
• Edges on 3D helpers
  

Dimensions:

Numbers and letters should fit into a x-z grid of a:

• 20 x 20 LDU
  
• 40 x 40 LDU
  

[Philippe Hurbain]

Looks good to me. About category, "helper" must be added to approved category list.
https://www.ldraw.org/article/340.html

[Roland Melkert]

My thoughts:

Naming convention:
h/<setName>_<numberOrName>.dat

Description:
No prefix, the 'h/' folder already indicates it's a non standard part.

If we put "Helper" in the category meta the description can be free to fill in by the author.

Maybe only use a prefix to indicate the 'set' of helpers it belong to, but even this should be up to the author of the set.

Category:
I would recommend making this mandatory "HELPER", so the description if free to use.

Keywords:
The type or "qualifier" should be put here, e.g. "3D arrow", "2D arrow", "Arrow" (can be together with 2D arrow).

Location:
<LibraryRoot>/parts/h

Design:
Only orientation should be formalized.

Dimensions:
Again up to the author imho.



In short I would like to leave as much freedom to the helper (set) authors as possible.

[Milan Vančura]

My thoughts:

I absolutely 100% agree with everything Roland summarized. This way authors have a big freedom and users have benefits of standardization. Win-win.

[Willy Tschager]

> In short I would like to leave as much freedom to the helper (set) authors as possible.

Description:

If there wouldn't have been a strict nomenclature for parts right from the beginning we would have "Bricks" and "Stone" and "Part" with "Studs" and "Heads" and a "3001.dat - Brick with 4 Connectors on 2 Rows on the top" in the library.

Dimension:

I further think that the dimension of letters and numbers should be defined. Otherwise you might have to scale a letter by 2 and a number by 3.1 to get the same height. Or a Times Roman by 2 and an Arial by 4.

w.

[Milan Vančura]

I absolutely 100% agree with everything Roland summarized. This way authors have a big freedom and users have benefits of standardization. Win-win.

I add some details, thoughts:

Using Category ("Helper") the part description is more free to mention a helper set name as the first word. For example "Arrow" or "Arrow3D". Then, of course, other authors must follow this rule to announce their helper is a part of this set. But I feel it's impossible to standardize anything more about names because we cannot predict what kind of helpers people come with, in future. So let them to discuss that when time comes, for each helper set.

Same for rules about edges,as an example. Even now we can see some arrows are to be without edges but another have edges (i.e. Jaco's ones). So why to set any rule about edges yes/no if we know we cannot see the future needs? Crystal balls are too expensive these days...

The only rule about edges I vote for is "do not set any other edge color than the standard one. If you need such thing, find another solution." For example, as you told me to improve the set of plain arrows: instead of edges of color16 remove edges at all.

This way (of thinking about the standard) I believe the problems Willy raised (chaos in descriptions etc.) will be solved, the result sets of helpers are easy to find and easy to sort => easy to use, and the freedom needed to be able to add another helper or helper set in future is not blocked.

I think Roland summarized it well and I agree with it, I just added some details - maybe we can refine some points so it is clear how to prevent problems Willy mentioned.

[Roland Melkert]

Using Category ("Helper") the part description is more free to mention a helper set name as the first word. For example "Arrow" or "Arrow3D". Then, of course, other authors must follow this rule to announce their helper is a part of this set. But I feel it's impossible to standardize anything more about names because we cannot predict what kind of helpers people come with, in future. So let them to discuss that when time comes, for each helper set.

With a "Set" I was more thinking about the whole collection a certain author maintains, like:

"Roland's flat arrows - short single"
"Roland's flat arrows - short dual"
"Roland's flat arrows - long single"

A bit like some brand's line of interconnecting products or something.

[Milan Vančura]

With a "Set" I was more thinking about the whole collection a certain author maintains, like:

Yes, this is how it starts. But, as we live in open-source world, another authors add something in future. Or if the original author is no longer active in ldraw etc.

[Willy Tschager]

With a "Set" I was more thinking about the whole collection a certain author maintains, like:

"Roland's flat arrows - short single"
"Roland's flat arrows - short dual"
"Roland's flat arrows - long single"

A bit like some brand's line of interconnecting products or something.

Like this a lot! Cannot wait to submit my helpers as:

"Willy's ego desperately needs this helper to be added to the part library - Arrow 3D"

w.

[N. W. Perry]

With a "Set" I was more thinking about the whole collection a certain author maintains, like:

"Roland's flat arrows - short single"
"Roland's flat arrows - short dual"
"Roland's flat arrows - long single"

A bit like some brand's line of interconnecting products or something.

"Roland's flat arrows" sounds like a group of storybook characters my son would enjoy. 

[Manfred Schaefer]

Hello,

what is the current status on this issue?

Greeting
Manfred

[Orion Pobursky]

Hello,

what is the current status on this issue?

Greeting
Manfred

Awaiting the ability to submit to the tracker and have them included in releases. Since this would require extensive modification to the existing software, it has been deferred until the new PT software can be brought online (currently targeted for the 2023-1 release in February but that, as always, is dependent on my real life free time).

[Manfred Schaefer]

Awaiting the ability to submit to the tracker and have them included in releases. Since this would require extensive modification to the existing software, it has been deferred until the new PT software can be brought online (currently targeted for the 2023-1 release in February but that, as always, is dependent on my real life free time).

Hello Orion,

thank you for your feedback. I am glad that this topic will be realized and this topic is not forgotten.

Greeting

Manfred

[Manfred Schaefer]

Hello Orion,
is there any news on this subject?
I would still have the following suggestion.
Additionally a directory "Obsolete" could be introduced. In this directory all elements which are marked as obsolete or have the note "Moved to" will be moved.
This would tidy up the library a bit.
About the one extension in the search path, these elements would still be available.
Greetings

Manfred

[Travis Cobbs]

I would still have the following suggestion.
Additionally a directory "Obsolete" could be introduced. In this directory all elements which are marked as obsolete or have the note "Moved to" will be moved.
This would tidy up the library a bit.

This change would not be backwards compatible. All LDraw-compatible software programs would have to update to support the new Obsolete directory, and that's not even possible since some programs (like MLCad) are no longer maintained.

[Manfred Schaefer]

This change would not be backwards compatible. All LDraw-compatible software programs would have to update to support the new Obsolete directory, and that's not even possible since some programs (like MLCad) are no longer maintained.

I don't understand.
The paths in which parts are to be searched for can be set or additional paths can be added to the standard paths. For example in MLCAD these paths are defined in the INI file. In LPub3D there is a menu for the search paths.

Greetings

Manfred

[Willy Tschager]

I don't understand.
The paths in which parts are to be searched for can be set or additional paths can be added to the standard paths. For example in MLCAD these paths are defined in the INI file. In LPub3D there is a menu for the search paths.

All the extra paths add additional value and you have to know how to add the paths and where. All LDraw programs work flawlessly and backwards with the p and parts folder.

w.

[Travis Cobbs]

I don't understand.
The paths in which parts are to be searched for can be set or additional paths can be added to the standard paths. For example in MLCAD these paths are defined in the INI file. In LPub3D there is a menu for the search paths.

While it's true that many LDraw programs allow for custom paths, not all do. Additionally, requiring users to do this just so that they can load LDraw files created in the past is not a good user experience. Finally, ignoring all that, suddenly adding a new "standard" LDraw directory and stating that moved-to parts all need to go there is definitely not backwards compatible. It is the very definition of "not backwards compatible".

[Manfred Schaefer]

While it's true that many LDraw programs allow for custom paths, not all do. Additionally, requiring users to do this just so that they can load LDraw files created in the past is not a good user experience. Finally, ignoring all that, suddenly adding a new "standard" LDraw directory and stating that moved-to parts all need to go there is definitely not backwards compatible. It is the very definition of "not backwards compatible".

Okay, if there are programs that do not support additional directories, then my suggestion makes no sense.

Greetings

Manfred

[Max Murtazin]

Okay, if there are programs that do not support additional directories, then my suggestion makes no sense.

Greetings

Manfred

Basically any fundamental change of the standard is out of the question. Only case when additional directories got a pass as far as I know was texture mapping - completely new feature that didn't require changing any old structure of the standard

[Eugen]

Design:

• No edges on 2D helpers as for stickers
  
• Edges on 2D helpers as for parts
  
• Edges Yes/No on 2D helpers - leave the final decision to the author
  
• Edges on 3D helpers
  

Dimensions:

Numbers and letters should fit into a x-z grid of a:

• 20 x 20 LDU
  
• 40 x 40 LDU
  

Small addition, as there is the first "Helpers 2D ..." part to test: https://library.ldraw.org/tracker/37573

I would recommend to add a note that if the "Helpers 2D ..." part is designed to be laid on the flat part (on top or on its side, as many rulers) there should be an offset added for helpers' edges/faces from the base plane set to something like "0.1 LDU" (this is minimal value to input manual transformation in LeoCAD), so when helper would be snapped to the part top/side there would be no Z-fighting between faces.

Here are screenshots of LeoCAD with actual "parts/helpers/helper2druler100ldu.dat" (for each case with show "Edge Lines" turned ON and OFF).

With no offset (as it is in latest revision of https://library.ldraw.org/tracker/37573)

       

With "0.1 LDU" offset:

       

[Willy Tschager]

Hardcoding an offset would limit its usage to one side only - as soon as you rotated it by 180° it would vanish into the parts.

w.

[Eugen]

Hardcoding an offset would limit its usage to one side only - as soon as you rotated it by 180° it would vanish into the parts.

w.

For the case where helpers has text labels in specific script (i.e., left-to-right for Latin) there is only one side which could be used as front side on top of a referenced part.

But for all the possible cases Z-fighting in labels could be avoided just by duplicating labels in helpers files with offset "0.1 LDU" from origin on both sides — in such case at least one label (of two) would be always ontop of the parts' faces which would be coplanar with helpers' origins (another label would be inside the part).

Here is LeoCAD with duplicated "Helper 2D Ruler 100 LDU", offsetted from origin "0.1 LDU" and "-0.1 LDU" accordingly.

   

[Willy Tschager]

   
   

w.

[Eugen]

[screenshots without description]

w.

Two issues:

1. On your screenshots there is no duplicated label with the negative offset (see my previous comment with the notes on duplicating labels; note that negative offset labels faces should has normals flipped);
   
2. Placing the ruler behind the object is not the way to correctly measure objects.
   

[Rene Rechthaler]

should the "markers" be very tall and thin pyramids? then it could get used to measure tip-to-tip...
(if it needs to get rotated for example)

[Willy Tschager]

1. Placing the ruler behind the object is not the way to correctly measure objects.
   

So you're gonna tell people the right way how to measure things? Or shall we leave it to the user how and where to place a ruler, with maximum freedom in regard of the origin and rotation center?

w.

[Willy Tschager]

should the "markers" be very tall and thin pyramids? then it could get used to measure tip-to-tip...
(if it needs to get rotated for example)

As this is a 2D helper triangles are doable.

w.