From Willy: Define a standard for helper parts


From Willy: Define a standard for helper parts
#1
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.
Reply
RE: From Willy: Define a standard for helper parts
#2
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.
Reply
RE: From Willy: Define a standard for helper parts
#3
(2021-08-18, 23:57)Travis Cobbs Wrote: 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 Big Grin , but since then, I'd simply number helpers as they come: h0001, h002...
Reply
RE: From Willy: Define a standard for helper parts
#4
(2021-08-18, 23:57)Travis Cobbs Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#5
(2021-08-19, 12:35)Willy Tschager Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#6
(2021-08-19, 15:39)Orion Pobursky Wrote: 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?
Reply
RE: From Willy: Define a standard for helper parts
#7
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.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: From Willy: Define a standard for helper parts
#8
(2021-08-19, 17:10)Travis Cobbs Wrote: 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 Smile

Just my explanation. Nothing more.
Reply
RE: From Willy: Define a standard for helper parts
#9
(2021-08-19, 12:35)Willy Tschager Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#10
(2021-08-19, 15:39)Orion Pobursky Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#11
(2021-08-20, 7:13)Willy Tschager Wrote: 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).
Reply
RE: From Willy: Define a standard for helper parts
#12
(2021-08-20, 7:34)Willy Tschager Wrote: 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.
Chris (LDraw Parts Library Admin)
Reply
RE: From Willy: Define a standard for helper parts
#13
(2021-08-20, 8:03)Milan Vančura Wrote: 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:

Quote: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.
Reply
RE: From Willy: Define a standard for helper parts
#14
(2021-08-19, 17:10)Travis Cobbs Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#15
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
Reply
RE: From Willy: Define a standard for helper parts
#16
(2021-08-18, 23:57)Travis Cobbs Wrote: 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"
Reply
RE: From Willy: Define a standard for helper parts
#17
(2021-08-20, 20:05)Travis Cobbs Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#18
(2021-08-21, 18:51)Roland Melkert Wrote: 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."
Reply
RE: From Willy: Define a standard for helper parts
#19
(2021-08-21, 18:51)Roland Melkert Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#20
(2021-08-21, 18:51)Roland Melkert Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#21
(2021-08-22, 7:37)Milan Vančura Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#22
(2021-08-21, 18:51)Roland Melkert Wrote: 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"
Reply
RE: From Willy: Define a standard for helper parts
#23
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
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#24
Looks good to me. About category, "helper" must be added to approved category list.
https://www.ldraw.org/article/340.html
Reply
RE: From Willy: Define a standard for helper parts
#25
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.
Reply
RE: From Willy: Define a standard for helper parts
#26
(2021-09-15, 17:57)Roland Melkert Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#27
> 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#28
(2021-09-16, 6:49)Milan Vančura Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#29
(2021-09-24, 8:03)Milan Vančura Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#30
(2021-09-25, 19:08)Roland Melkert Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#31
(2021-09-25, 19:08)Roland Melkert Wrote: 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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#32
(2021-09-25, 19:08)Roland Melkert Wrote: 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.  Smile
Reply
RE: From Willy: Define a standard for helper parts
#33
Hello,

what is the current status on this issue?

Greeting
Manfred
Reply
RE: From Willy: Define a standard for helper parts
#34
(2022-11-08, 21:28)Manfred Schaefer Wrote: 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).
Reply
RE: From Willy: Define a standard for helper parts
#35
(2022-11-08, 21:55)Orion Pobursky Wrote: 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
Reply
RE: From Willy: Define a standard for helper parts
#36
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
Reply
RE: From Willy: Define a standard for helper parts
#37
(2023-04-24, 19:40)Manfred Schaefer Wrote: 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.
Reply
RE: From Willy: Define a standard for helper parts
#38
(2023-04-24, 20:15)Travis Cobbs Wrote: 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. Sad
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
Reply
RE: From Willy: Define a standard for helper parts
#39
(2023-04-24, 20:44)Manfred Schaefer Wrote: I don't understand. Sad
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.
LEGO ergo sum
Reply
RE: From Willy: Define a standard for helper parts
#40
(2023-04-24, 20:44)Manfred Schaefer Wrote: I don't understand. Sad
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".
Reply
RE: From Willy: Define a standard for helper parts
#41
(2023-04-24, 20:51)Travis Cobbs Wrote: 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
Reply
RE: From Willy: Define a standard for helper parts
#42
(2023-04-25, 7:11)Manfred Schaefer Wrote: 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
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)