New meta in LDConfig for default category icon in editors

[Willy Tschager]

Dear LSB,

please read:

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

and have your say.

w.

[Orion Pobursky]

Just to formalize this a bit:

The !MASCOT meta command is intended to allow editor to display a typical example of a part in a given category (as defined by the !CATEGORY meta). It will appear in the LDConfig.ldr for editors to reference. If a !MASCOT statement for a given !CATEGORY is not present, then the mascot may be chosen by the developer

Syntax
!MASCOT CATEGORY "<category>" DESCRIPTION "<description>" PART <rotation maxtrix> <part file>

Where:
<category> is the 1 or 2 word category from the list of approved !CATEGORY categories
<description> is a short (approximately 4 words or less) of the category. This will typically be the pluralized form of the category
<rotation matrix> is the 9 digit rotation matrix as defined by the LDraw File Format Type 1 line definition
<part file> is the part file reference as defined by the LDraw File Format Type 1 line definition

[Travis Cobbs]

Just to formalize this a bit:

The !MASCOT meta command is intended to allow editor to display a typical example of a part in a given category (as defined by the !CATEGORY meta). It will appear in the LDConfig.ldr for editors to reference. If a !MASCOT statement for a given !CATEGORY is not present, then the mascot may be chosen by the developer

Syntax
!MASCOT CATEGORY <category> DESCRIPTION "<description>" PART <rotation maxtrix> <part file>

Where:
<category> is the 1 or 2 word category from the list of approved !CATEGORY categories
<description> is a short (approximately 4 words or less) of the category. This will typically be the pluralized form of the category
<rotation matrix> is the 9 digit rotation matrix as defined by the LDraw File Format Type 1 line definition
<part file> is the part file reference as defined by the LDraw File Format Type 1 line definition

I notice that you removed the quotes around category that Roland suggested. If a program already needs to have quote parsing for description, it seems that having quotes around the category makes sense.

I personally feel that AVATAR is a better name for this than MASCOT. However, I'm ok with MASCOT if others prefer it over AVATAR.

[Orion Pobursky]

Oversight on my part. I do like AVATAR better. 
I did remove around the part file as per library spec there will never have a space in the file name.

[Travis Cobbs]

Oversight on my part. I do like AVATAR better. 
I did remove around the part file as per library spec there will never have a space in the file name.

While the part file may never have spaces, the category will, and those are the quotes I was talking about.

[Orion Pobursky]

I agree, edited above.

[Roland Melkert]

!MASCOT CATEGORY "<category>" DESCRIPTION "<description>" PART <rotation maxtrix> <part file>

I'm ok with avatar instead of mascot.

Not sure about loosing the quotes around the part file though. It's true the spec forces whole words but that is the current spec. Also it seems more consistent to use it for all string variables. That said it's not really a show stopper for me so I'm ok ether way just my 2cts.

nitpick:

If a !MASCOT statement for a given !CATEGORY is not present, then the mascot may be chosen by the developer

This sounds a bit preachy, imho, maybe:

If a !MASCOT statement for a given !CATEGORY is not present, then the selection of the mascot is entirely up to the developer

Because meta or not the developer can choose not to use them at all, the 'may' suggests it MUST be used.

[Travis Cobbs]

I'm ok with avatar instead of mascot.

Not sure about loosing the quotes around the part file though. It's true the spec forces whole words but that is the current spec. Also it seems more consistent to use it for all string variables. That said it's not really a show stopper for me so I'm ok ether way just my 2cts.

nitpick:

This sounds a bit preachy, imho, maybe:

Because meta or not the developer can choose not to use them at all, the 'may' suggests it MUST be used.

Actually, 'may' typically has a very explicit definition in technical specifications:

https://www.ietf.org/rfc/rfc2119.txt

[Roland Melkert]

Actually, 'may' typically has a very explicit definition in technical specifications:

https://www.ietf.org/rfc/rfc2119.txt

It might be the language barrier but I read it like:

The developer MUSt use the mascots given by the metas, if no meta is present for some category the develop MAY make one up them selves.

[Orion Pobursky]

The developer MUSt use the mascots given by the metas, if no meta is present for some category the develop MAY make one up them selves.

That's kind of the intent. Much like the COLOUR meta, if you decide to implement support for the MASCOT meta then you have to honor the ones in LDConfig. Not doing so would cause user confusion when they changed something and it wasn't reflected in the supporting programs.

[Roland Melkert]

That's kind of the intent. Much like the COLOUR meta, if you decide to implement support for the MASCOT meta then you have to honor the ones in LDConfig. Not doing so would cause user confusion when they changed something and it wasn't reflected in the supporting programs.

Yes but I somehow assumed the developer has no say about if they want the metas at all.

Sorry for the confusion.

[Orion Pobursky]

Here's a link to the draft spec.

I softened the language at bit. I also put the quite back around the filename since it's not really that big of a deal to me.

https://www.ldraw.org/avatar-spec.html

[Travis Cobbs]

Here's a link to the draft spec.

I softened the language at bit. I also put the quite back around the filename since it's not really that big of a deal to me.

https://www.ldraw.org/avatar-spec.html

Some suggestions based on what is there now:

1. "allow editor" -> "allow an editor"
   
2. "For editor" -> "For an editor"
   
3. "or less) of the category" -> "or less) description of the category"
   
4. "9 digit rotation" -> "9 element rotation"
   

Note: a digit is a single character 0-9, so the rotation matrix cannot be 9 digit. I'm not sure "element" is the best word here, but think that it works well.

[Roland Melkert]

I think we can remove the "1 or 2 word" restriction from category as the quotes make that a non issue. This way we don't have to change this spec if the category spec ever allows more then 2 words.

And maybe restrict the rotation matrix to a pure one (no scaling, skewing, etc).

Meaning it is a sequence of 9  -1.0 .. 1.0 (float?) numbers.

[Willy Tschager]

Some suggestions based on what is there now:

1. "allow editor" -> "allow an editor"
   
2. "For editor" -> "For an editor"
   
3. "or less) of the category" -> "or less) description of the category"
   
4. "9 digit rotation" -> "9 element rotation"
   

Note: a digit is a single character 0-9, so the rotation matrix cannot be 9 digit. I'm not sure "element" is the best word here, but think that it works well.

I added the above corrections. Roland's remarks are technical and therefore your sandbox.

w.

[Travis Cobbs]

I think we can remove the "1 or 2 word" restriction from category as the quotes make that a non issue. This way we don't have to change this spec if the category spec ever allows more then 2 words.

And maybe restrict the rotation matrix to a pure one (no scaling, skewing, etc).

Meaning it is a sequence of 9  -1.0 .. 1.0 (float?) numbers.

I agree that "1 or 2 word" should be removed. Perhaps us this instead:

<category> is the category name from the list of approved !CATEGORY categories

I don't have a problem with restricting the matrix to be rotations only, but I'm not sure what good wording for that would be. Maybe:

<rotation matrix> is the 9 element rotation matrix as defined by the LDraw File Format Type 1 line definition. Only rotations are allowed in this matrix, not scale factors or skews.

[Roland Melkert]

<rotation matrix> is the 9 element rotation matrix as defined by the LDraw File Format Type 1 line definition. Only rotations are allowed in this matrix, not scale factors or skews.

I'm ok with that.

Should we vote on this?

[Roland Melkert]

Just though about one minor issue:

Must the given part actually be in the same category? If so it must be mentioned somewhere.

[Orion Pobursky]

Just though about one minor issue:

Must the given part actually be in the same category? If so it must be mentioned somewhere.

I don't think so. This is for users. Let them decide what they want. Same for rotation. Any valid matrix. If it looks weird, that's on you.

[Roland Melkert]

I don't think so. This is for users. Let them decide what they want. Same for rotation. Any valid matrix. If it looks weird, that's on you.

I thought the meta was mainly for LDConfig.ldr? So it's more of a library thing than a user one imho.

[Willy Tschager]

I thought the meta was mainly for LDConfig.ldr?

Correct! And being the maintainer of the LDConfig.ldr it is mainly for me ;-)

w.

[Orion Pobursky]

I thought the meta was mainly for LDConfig.ldr? So it's more of a library thing than a user one imho.

Just like the color defs, it is user editable. Less restrictions are better IMO.

[Roland Melkert]

Just like the color defs, it is user editable. Less restrictions are better IMO.

You mean standard wise?

As forcing it to be something logical for the official LDConfig.ldr seems a must to me.

I'm ok with no restrictions outside library use, but I do think we should at least warn/encourage people to use non scaling/skewing rotation matrices only.

[Orion Pobursky]

You mean standard wise?

As forcing it to be something logical for the official LDConfig.ldr seems a must to me.

I'm ok with no restrictions outside library use, but I do think we should at least warn/encourage people to use non scaling/skewing rotation matrices only.

The library standard will always be stricter than the general standard. For the library I intend to restrict to a non-scaling, non-skew matrix.

[Roland Melkert]

The library standard will always be stricter than the general standard. For the library I intend to restrict to a non-scaling, non-skew matrix.

I would restrict the matrix for all use but It's no deal breaker.

Should we vote on this?

[Orion Pobursky]

The matrix will be restricted for the official LDConfig.ldr and it's alt file.

Let's vote.

I vote Yes.

[Travis Cobbs]

The matrix will be restricted for the official LDConfig.ldr and it's alt file.

Let's vote.

I vote Yes.

I vote Yes.

[Roland Melkert]

I vote Yes.

[Willy Tschager]

Many Thanks to the LSB. I updated the specs with your last modifications and published the document.

https://www.ldraw.org/avatar-spec.html

w.