Bloat the library with shortcuts

[Willy Tschager]

Guys,

I came across this part:

Door  1 x  4 x  6 Smooth with Chamfered Handle Plinth with Boxing Ring Poster Sticker

and would like to discuss the usefulness of our shortcuts in general with a spot on applied sticker shortcuts. My opinion on this is that if we start creating shortcuts for every sticker the library gets bloated in an unnecessary way. I actually propose to obsolete the already official sticker shortcuts.

w.

[Philippe Hurbain]

I actually propose to obsolete the already official sticker shortcuts.

I somewhat agree with you, but I'm less radical: flat stickers on a tile or side of a brick are useless imho, but formed stickers, stickers on slopes, etc are more tricky to use, so in this case shortcuts are helpful.

[Orion Pobursky]

I somewhat agree with you, but I'm less radical: flat stickers on a tile or side of a brick are useless imho, but formed stickers, stickers on slopes, etc are more tricky to use, so in this case shortcuts are helpful.

Philo beat me to this. I agree with him.

[Gerald Lasser]

I would not go that far to obsolete the shortcuts that are in the library right know. I really don't know how many there are.

I have the same opinion on flat stickers, they are easy to apply and positioning is no big deal. I even think I have also submitted such shortcuts for some train parts.

For the flat stickers my proposal would be to include the default position in a !HELP line or a !CMDLINE. The programs shoudl read the HELP/CMDLINE information and display it.

Flat Stickers on even but slanted surfaces MAY be a value add, but that could also be handled with a !HELP Line

Formed Stickers provide a value add in my opinion, and adding them on round pieces could proove tricky

[Magnus Forsberg]

To me, they're no different than patterned parts clogging up the partbins in LDCad.
I wish I could first pick the right part/shape, and then choose the pattern/sticker on that part.

It's not the many shortcuts that bother me, rather the sorting in the partbins.

[Gerald Lasser]

To me, they're no different than patterned parts clogging up the partbins in LDCad.
I wish I could first pick the right part/shape, and then choose the pattern/sticker on that part.

It's not the many shortcuts that bother me, rather the sorting in the partbins.

That is a very good point. Adding a small (+) to extend the patterns a part is decorated would help manage the parts.

[Philippe Hurbain]

That is a very good point. Adding a small (+) to extend the patterns a part is decorated would help manage the parts.

Can't agree more!

[Chris Dee]

For the flat stickers my proposal would be to include the default position in a !HELP line or a !CMDLINE. The programs shoudl read the HELP/CMDLINE information and display it.

This is a good suggestion, but should use a new directive, not piggy-back !HELP or !CMDLINE. For example, in 193075a.dat, we could add

Code:

0 !APPLYTO 4181.dat 1 16 10 96 30 0 -1 0 0 0 -1 1 0 0 193075a.dat
0 !APPLYTO 4182.dat 1 16 -10 96 30 0 1 0 0 0 -1 -1 0 0 193075a.dat

[Mikkel Bech Jensen]

I actually think it is useful that some stickers are already applied, even for flat surfaces where it would be super easy to apply them. I really hate going through all the stickers to find the right size and then be able to find the right pattern, if it is even there!. It is really annoying when you are not sure that has even been made or is availbale on the parts tracker. Many stickers are only intended to applied to a specific part and I really like when those can be chosen in the libarary already applied the same way you would find a patterned version of the part. Of course there are many situations where the same sticker is used for different parts in different sets and there are also many cases where a sticker is applied over multiple parts where it  would not make sense to make a shortcut of it.

I think locating stickers is a big problem with Ldraw and I think making these shortcuts is a good thing despite them "bloating" the library.

[Orion Pobursky]

I think locating stickers is a big problem with Ldraw

I'm curious about this statement. What, exactly, is difficult about finding stickers in the library?

[Travis Cobbs]

This is a good suggestion, but should use a new directive, not piggy-back !HELP or !CMDLINE. For example, in 193075a.dat, we could add

Code:

0 !APPLYTO 4181.dat 1 16 10 96 30 0 -1 0 0 0 -1 1 0 0 193075a.dat
0 !APPLYTO 4182.dat 1 16 -10 96 30 0 1 0 0 0 -1 -1 0 0 193075a.dat

I wonder if the redundant information is a good thing or a bad thing. On the plus side, having a fully valid type 1 line show up at the end of the meta command has a certain appeal. On the other hand, the 1 at the beginning, and the 193075a.dat at the end, is redundant information that we already know based on context.

[Roland Melkert]

I wonder if the redundant information is a good thing or a bad thing. On the plus side, having a fully valid type 1 line show up at the end of the meta command has a certain appeal. On the other hand, the 1 at the beginning, and the 193075a.dat at the end, is redundant information that we already know based on context.

I agree.

Code:

0 !APPLYTO 4181.dat 16 10 96 30 0 -1 0 0 0 -1 1 0 0
0 !APPLYTO 4182.dat 16 -10 96 30 0 1 0 0 0 -1 -1 0 0

seems more clear.

Not too sure about the meta name though, e.g. "!COMPATIBLE" might be more obvious.

[Travis Cobbs]

Not too sure about the meta name though, e.g. "!COMPATIBLE" might be more obvious.

Given that it provides all the information needed to apply the sticker to the given part, I feel that APPLYTO is much better than COMPATIBLE. Realistically, a flat sticker is "compatible" with any part with a flat region big enough to hold the sticker.

[Roland Melkert]

Given that it provides all the information needed to apply the sticker to the given part, I feel that APPLYTO is much better than COMPATIBLE. Realistically, a flat sticker is "compatible" with any part with a flat region big enough to hold the sticker.

I was thinking to also use it for e.g. Tyre/Rim cross linking.

[Travis Cobbs]

I was thinking to also use it for e.g. Tyre/Rim cross linking.

In that case, I think "!ATTACHTO" (or "!ATTACH_TO") would be more appropriate. The point is that the part is being attached at a specific location on another part, so "!COMPATIBLE" isn't strong enough.

[Mikkel Bech Jensen]

I'm curious about this statement. What, exactly, is difficult about finding stickers in the library?

There are so many and I find the way they are organised confusing. I know they are organised by size but I find it annoying that the sticker I am looking for could either be "Sticker 0.8 x  3.9", "Sticker 0.9 x  3.9" or "Sticker 1.0  x  3.9". It is not as easy to know the dimensions of the stickers beforehand as it is with regular parts. I don't have a better suggestion for how the stickers should be categorised, but I have been happy for the shortcuts as I find it faster to find a part with a sticker applied than finding the correct sticker in the sticker category.

I just think it is a problem to identify stickers in ldraw. You can't really get hints from bricklink and peeron the same way as you can with parts. Or maybe I just don't know a proper way to do it. I don't think there is a better way to organise them, I just think it is annoying the way it has to be with stickers.

[Mikkel Bech Jensen]

Maybe this is just a personal issue, or it depends on the editor. But I was recently trying to build an old lego police station by following the instruction online. The stickers was really annoying to identify and while I had the impression that they were all there, I concluded for some that they weren't in either the official or the unofficial library. It is just not the same problem as with regular parts.

I don't hope I am the only one who have been in that frustrating situation?

[Steffen]

...
and would like to discuss the usefulness of our shortcuts in general with a spot on applied sticker shortcuts.
...
I actually propose to obsolete the already official sticker shortcuts.

Hi,

I strongly disagree. Additionally I strongly disagree with introducing a new keyword for applying stickers.
Here are my reasons:

(1)
There is no new keyword for applying a sticker needed because we already have a syntax for that.
That is the normal "type 1" line which puts a sticker on a part.

(2)
Putting a sticker on a part is just an "implementation detail" to get a "pattern" onto that part.
In some cases, LEGO decided to print it directly onto the part,
in some cases, LEGO decided to create a sticker instead.
For an end user of LDRAW it does not really matter how the colors get onto a part, he just builds with the bricks we provide.

(3)
For that reason, having the "d01, d02, d03, ..." shortcuts which provide a "part+sticker" assembly
is the same clutter as if we would have "p01, p02, p03, ..." files providing a pattern.
The fact that LEGO decided to make a sticker instead of a pattern is not our fault.
The number of parts for a builder is the same.

(4)
I do not feel the stickered parts to be clutter. I frequently need and use them in my building,
and I do not want to search for stickers separately. Usually I normally do not know if some image I see
is a sticker or a pattern print. I just choose the right brick from the brick preview.

keep enjoying the holidays
Steffen

[Willy Tschager]

For that reason, having the "d01, d02, d03, ..." shortcuts which provide a "part+sticker" assembly
is the same clutter as if we would have "p01, p02, p03, ..." files providing a pattern.
The fact that LEGO decided to make a sticker instead of a pattern is not our fault.
The number of parts for a builder is the same.

You're wrong. Having the pattern detached from the part gives you the freedom to flood the library with, say, a brick 1x4 + sticker, 1x6 + sticker, brick 1x6 + sticker, bricker 2x4 + sticker, brick 2x6 + sticker ... and tile 1x4 + sticker, tile 1x6 + sticker, ...

We have no rules that the sticker shortcut is limited to the official assembly used in the official set.

w.

[Travis Cobbs]

I disagree for two reasons:

1. Stickers, being a separate object that has to be applied, really is different from a pattern. The only way to support patterns in LDraw is to have separate "patterned parts". If patterns had always been implemented in LDraw as textures, then that wouldn't be the case, since an arbitrary pattern texture can be applied to any arbitrary part, but it is the case.
   
2. In LEGO instructions, stickers are added after the fact at arbitrary times.
   

Having said the above, I'm not a part author, nor do I create LDraw models, so I don't think my opinion should carry much weight with respect to whether or not this is a good idea.

[Steffen]

I see your point.

Maybe we can agree on a compromise like this:

"for a sticker, only 1 parent shortcut is allowed (exceptions possible of course),
so that the "default stickered part" can be used analogously to patterned parts"

?

[Johann Eisner]

I see the whole thing like this:
Stickers are separate components for me.
We could list the set in the header of the sticker where the sticker was first used (as with the printed parts).

Shortcuts from straight stickers are also superfluous for me.
I'm not strictly against shortcuts when it comes to shaped stickers, but in my opinion they don't have to be.
While I was writing these lines, Steffen replied, (#21) and I also like this approach.
I just tore something back and forth.

[Willy Tschager]

I see your point.

Maybe we can agree on a compromise like this:

"for a sticker, only 1 parent shortcut is allowed (exceptions possible of course),
so that the "default stickered part" can be used analogously to patterned parts"

?

Things are easy at first sight, but (there is always a but) what when it comes to shortcuts using several parts:



* Or the same sticker reused in another set on different bricks?

* Do we really want to have a Minifig Torso with the Classic Space Logo + a plain torso with the classic space logo sticker shortcut:



To be honest I don't see the benefit of having a shortcut of:

https://www.ldraw.org/cgi-bin/ptdetail.c...20377a.dat

while I also have:

https://www.ldraw.org/cgi-bin/ptscan.cgi?q=6636p10

That is the bloat I'm talking about.

w.

[Gerald Lasser]

To be honest I don't see the benefit of having a shortcut of:

https://www.ldraw.org/cgi-bin/ptdetail.c...20377a.dat

while I also have:

https://www.ldraw.org/cgi-bin/ptscan.cgi?q=6636p10

That is the bloat I'm talking about.

w.

Willy, I do not see this example as bloat, the two parts you mentioned are essentially two different things or did I get you wrong?

[Steffen]

The large stickers, covering multiple bricks don't need a shortcut IMHO.

But for the default case where 1 sticker is applied to 1 part, I think we should provide that in the library because
the difference between that one and a patterned part is not really feelable by a user.

Remember that you as a kid only also applied a sticker once to a part, and then left it there. Otherwise you would ruin it.
That part from there on was "patterned" in a kind of way.

That's why I want to have the standard "default part + sticker" assembly in our library, alongside with the patterned parts.

For me as a builder, these 2 kinds not really have a difference.

[Orion Pobursky]

The large stickers, covering multiple bricks don't need a shortcut IMHO.

But for the default case where 1 sticker is applied to 1 part, I think we should provide that in the library because
the difference between that one and a patterned part is not really feelable by a user.

Remember that you as a kid only also applied a sticker once to a part, and then left it there. Otherwise you would ruin it.
That part from there on was "patterned" in a kind of way.

That's why I want to have the standard "default part + sticker" assembly in our library, alongside with the patterned parts.

For me as a builder, these 2 kinds not really have a difference.

I agree with this. This ensures the sticker is properly centered or positioned without having to fiddle around with the grid setting etc. We provide shoe it for other things and, especially, if we’re still going to do curved sticker shortcuts then we should do flat ones as well. “Bloat” isn’t really a big deal to me since it’s easy to filter these types of parts if you don’t want to see them.

[Philippe Hurbain]

I agree with this. This ensures the sticker is properly centered or positioned without having to fiddle around with the grid setting etc. We provide shoe it for other things and, especially, if we’re still going to do curved sticker shortcuts then we should do flat ones as well. “Bloat” isn’t really a big deal to me since it’s easy to filter these types of parts if you don’t want to see them.

There's also the bloated work for reviewers

[Willy Tschager]

The large stickers, covering multiple bricks don't need a shortcut IMHO.

The best rules are those with exceptions. I suggest that we also leave out all shortcuts where the non-sticker part is red and not a tile.

Remember that you as a kid only also applied a sticker once to a part, and then left it there. Otherwise you would ruin it.
That part from there on was "patterned" in a kind of way.

But this is the digital world, where all parts in all colors are available. Millions of bricks for your layout and tons of the same sticker which would cost a fortune at BL.

That's why I want to have the standard "default part + sticker" assembly in our library, alongside with the patterned parts.

I want that we add every combination of minifigs ever produced. I'm tired of updating the MLCad.ini twice a year or trying to stick a sword into a hand in LDCad.

w.

[Willy Tschager]

There's also the bloated work for reviewers

Not for me . Steffen submits them, Orion reviews them, Chris has to review them anyway. What we are looking for is someone with too much spare time - like you. You have to give us a chance to get closer to your 2000 parts mark.

w.

[Orion Pobursky]

The best rules are those with exceptions. I suggest that we also leave out all shortcuts where the non-sticker part is red and not a tile.


But this is the digital world, where all parts in all colors are available. Millions of bricks for your layout and tons of the same sticker which would cost a fortune at BL.


I want that we add every combination of minifigs ever produced. I'm tired of updating the MLCad.ini twice a year or trying to stick a sword into a hand in LDCad.

w.

Your hyperbole aside, I think there is use for sticker and minifig shortcuts for official sets. This brings up the fact that cycling everything through the PT is a bit excessive. So maybe we have a OMR style library with these combos. In fact, at least for official set minifig shortcuts, I think this is a fine idea.

P.S. I still don't understand why you find building minifigs in LDCad to be difficult. Part snapping and relative origin rotation make this a breeze.

[Travis Cobbs]

I agree with this. This ensures the sticker is properly centered or positioned without having to fiddle around with the grid setting etc. We provide shoe it for other things and, especially, if we’re still going to do curved sticker shortcuts then we should do flat ones as well. “Bloat” isn’t really a big deal to me since it’s easy to filter these types of parts if you don’t want to see them.

Assuming it became supported by LDCad (and hopefully LeoCAD), the proposed new meta-command (whatever it would be called) would allow for extremely easy application of stickers to parts, and ensure that they are applied in precisely the correct location. LDCad might even automatically group the two pieces (sticker and part) together. However, the meta-command is pretty much useless without editor support.

If Roland commits to supporting a meta-command, I personally feel that it is the best solution to the "sticker problem". And as he pointed out above, it could also be used to support wheels and tyres. A single sticker part could even potentially have multiple !ATTACHTO commands (although I'm not sure off-hand if there are any sets where multiple copies of the same sticker get applied to different parts, or different locations on the same part).

[Willy Tschager]

This brings up the fact that cycling everything through the PT is a bit excessive. So maybe we have a OMR style library with these combos. In fact, at least for official set minifig shortcuts, I think this is a fine idea.

As long as they don't have to be cycled through the PT you can do with sticker/minifig/whatever-shortcuts whatever you want.

w.

[Roland Melkert]

If Roland commits to supporting a meta-command, I personally feel that it is the best solution to the "sticker problem". And as he pointed out above, it could also be used to support wheels and tyres. A single sticker part could even potentially have multiple !ATTACHTO commands (although I'm not sure off-hand if there are any sets where multiple copies of the same sticker get applied to different parts, or different locations on the same part).

I'm willing to add it to 16d, that release is waiting on me to process the 1903 snapping data info anyway.

These new metas are basically snapping info too.

[Orion Pobursky]

As long as they don't have to be cycled through the PT you can do with sticker/minifig/whatever-shortcuts whatever you want.

w.

I'd like any "separate" solution to be officially recognized and distributed with the library as usable parts. You can filter them if you don't want to see them.

[Philippe Hurbain]

I'm willing to add it to 16d, that release is waiting on me to process the 1903 snapping data info anyway.

Good news!

I personally feel that it is the best solution to the "sticker problem".

I personally feel that too

[Vincent Messenet]

I'm curious about this statement. What, exactly, is difficult about finding stickers in the library?

As the topic is still discussed regularly on the PT I'd like to give my opinion too.

Regarding shortcuts for flat stickers on flat surface IMHO we should keep them in the library because:
1. As for patterned parts the PT provides a way to see all stickered versions of a part on a single page such as https://www.ldraw.org/cgi-bin/ptpatterns.cgi?d=3069b
I find it very useful as an end-user when building a model to see what is available as we would do with patterns.
2. It allows having a link with external libraries such as BL with a direct keyword to the assembly
3. It is not that time consuming to review them.

Also, I agree that we should only have shortcuts of official assemblies.

Then if we go with the introduction of a meta-command to replace these shortcuts I'd support the idea only if on LDraw website there would be a tool which:
1. Use this meta-command to display all stickers that can be attached to a part (to replace the current overview on PT)
2. And why not propose to download a .dat file shortcut generated on the fly

To finish there are shortcuts of flat stickers on flat surfaces that [color=#333333][color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif][size=small][size=small][font=Tahoma, Verdana, Arial, sans-serif]I feel we should continue to [/size][/font][/size][/color][color=#333333][size=small][size=small][font=Tahoma, Verdana, Arial, sans-serif]accept in the library because they [/size][/font][/size][/color]must be positioned on a specific part of the surface. For example [/font][/size][/color]https://www.bricklink.com/v2/catalog/catalogitem.page?P=60616pb004

[Magnus Forsberg]

To me, this should be a simple rule:
We should allow part+sticker shortcuts, or we don't. I see no reason to have an exception for flat sticker on flat parts.

[Orion Pobursky]

We had this debate back last summer. Our new rule was a compromise out of that and I really don't want to change things so soon again. 

Additionally, positioning a flat part on a flat surface is easy in all the major editors.  Positioning a curved part on a curved surface is non-trivial. Therefore there's a good case to be made for allowing the latter and not the former. If and when we adopt a part snapping standard and it is implemented in all major editors (currently LDCad and LeoCAD) we can revisit disallowing the rest of the sticker shortcuts.

[Willy Tschager]

I have short memory. We already ruled on this:

Part has to be deleted: https://www.ldraw.org/article/512.html#s..._shortcuts

w.