Wheel+Tyre Shortcuts: to have or not to have?

[Steffen]

I have just recently added some Wheel+Tyre Assembly Shortcuts to the PT.

http://www.ldraw.org/cgi-bin/ptdetail.cg...482c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...482c02.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...996c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...695c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...245c02.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...715c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...039c01.dat
and
http://www.ldraw.org/cgi-bin/ptdetail.cg...27ac01.dat
, which has sparked this discussion:

Magnus questions if having these makes sense.

I'd like to answer that question with my reasoning here.

The reason behind creating these shortcuts was that when building models,
I again and again found myself in 2 actions:

(a) searching the matching tyre for a wheel (because in MLCad all parts get scaled in the parts library preview, so all wheels and tyres look the same size)

(b) after I had found them, I to each model added a "wheel+tyre" assembly submodel

After having done this some times, I was asking myself why the assembly of (b)
was not part of the library.
Of course, the answer is: avoid clutter. As some wheels can carry different tyres, a combinatoric explosion
might occur. This prevented me some time from creating these shortcuts.
I then discovered that e.g. SR3DBuilder contains a separate database for this purpose: "TireManager.txt" (see attachment).
It is a simple text file which lists wheels plus their matching tyres.
When I saw that, I felt reminded of the discussion about 2 other things:
(i) alias part numbers
(ii) physical color shortcuts
There, the discussion was just the same: should we track this data somewhere?
The discussion about these 2 mainly went like this at those times:
First, an agreement was achieved that this information is quite valuable and needs to be stored somewhere.
The initial idea then was to have a separate database.
It then turned out that that separate database was nothing else than simple redirections
of part number to other part numbers, or of part numbers plus a certain color to other part numbers.
Then the question arose why we would create all the effort to maintain tooling etc. for a separate database,
when the existing mechanisms (i.e., LDRAW lines of type "1", part usage) would do everything we need.
Voila, a prefix was added to easily distinguish these files, and later, even an !LDRAW_ORG header type was added
(which I consider even better), and that was it. I find this solution very elegant, as it is self-contained and does
not add a secondary database.
When I remembered that, I felt that at least for the "usual" wheel+tyre assemblies, i.e., such that occur
in official LEGO models, we should have these shortcuts, basically for the same reasoning:
there is only a limited number of combinations possible, and that number is not too high:
SR3DBuilder's text file for example currently counts 165 such combinations.
Another disadvantage of that file is that it only lists matching part numbers, but it does not carry
information about the offset and orientation, and the color of the tyre. In fact, that text file is a stripped-down
instance of an LDRAW line type "1" (part usage), but without positioning, matrix and coloring element.
I felt that being a loss, and a step backward behind what our library already can do.
And I felt that these combinations should not be a private detail of tool SR3DBuilder, but of the library itself.
I cannot really see the "clutter" argument, as the number of these assemblies will be small, compared
to the plenty of physical color shortcut files we already have.

To make a long story short:
I would very much like to have these shortcuts in our library, at least for the wheel+tyre combinations
that occured in official LEGO models.

I'd like to hear your thoughts on this.

[Philippe Hurbain]

There are already many possibilities to find matching parts, so I see no real benefit for shortcuts.

[Orion Pobursky]

Also, when I do a part inventory of a model in order buy the parts to build it in real life, the wheel and the tyre need to be listed separately.

[Roland Melkert]

I think this is more of a connection information (LCD) issue.

Another reason to start getting serious about official connection information.

[Joshua Delahunty]

I have just recently added some Wheel+Tyre Assembly Shortcuts to the PT.
<snip>
I'd like to hear your thoughts on this.

To those who aren't sure this idea was necessary...

What do you feel about any such combinations that TLG counted as a single entity? Would you want/favor those being in the official library?

-- joshua

[Chris Dee]

If one views the LDraw library as an inventory, yes. But maybe these belong in another class of files identified by a new !LDRAW_ORG file type.

As a CAD resource, I'm not so sure they are needed.

Personally, I think they should be included.

[Greg Teft]

I think that the common shortcuts are a good thing.
Might not want to go crazy on all the possibilities, but at least the combinations that end up staying as one piece.
A few months ago, I had a bout of nostalgia, and made a bunch of models from the early '70s
I used a sub-file with this combination in almost all of them.

1 16 0 0 0 1 0 0 0 1 0 0 0 1 3137c01.dat
1 256 31 22 0 1 0 0 0 1 0 0 0 1 3139.dat
1 256 -31 22 0 1 0 0 0 1 0 0 0 1 3139.dat

Inventory generators can be updated to optionally recurse on dat files that are shortcuts using the file type.

[Roland Melkert]

As a result of this thread I was thinking about adding a 'related' feature to LDCad at some point.

Biggest problem with such a feature would be the information needed, so if anybody wants to take a go on compiling a list of related parts it would be a great help.

All is needed is simple lines in the form of (using names instead of numbers per example):

wheel10mm.dat tyreA10mm.dat tyreB10mm.dat

or even

leftWing3x8.dat rightWing3x8.dat

I could then convert such a list into a cross referenced internal format, and use it to populate the partbin based on the current selected part.

[Greg Teft]

Bricklink has a lot of that info - BrickLink Catalog Item Relationships.
It would need to be mined, I didn't see the match data in the available downloads.

[Steffen]

I suggest to not use a new text file format for that purpose.
The existing LDRAW format can combine two parts easily
AND position them correctly relative to one another:
1 16 ... ............ part1.dat
1 16 ... ............ part2.dat
That is what the shortcuts do.
As said, the issue is analogous to the physical color shortcuts:
there, instead of inventing a secondary database or format, we used the existing technique.
I like that approach of "keep it simple".

[Roland Melkert]

I think you misunderstood, I'm not trying to add this information to the library. I'm just wondering about compiling a list/db of related parts to use in my application to help users find 'related' parts without using alias parts.

[Roland Melkert]

Did not know that, but it's exactly what I need. Could use that info to fill the bin with the other parts in a 'match' set whenever you select a part that's also a member of that set in your model.

[Steffen]

I understood that.
My suggestion was to - even for that separate DB - not use or invent a new format,
but re-using the existing one, which in addition to your original suggestion allows
to position and orient parts together.

[Roland Melkert]

Ok, I think I understand what your meaning, but creating ldr files for every combination is going to explode count wise. Or I have to implement some kind of grouping meta so you can tell the parser in a single file which type 1 lines can be used together like macros.

[Jude Parrill]

Perhaps I'm mistaken on this, but couldn't you also use the already-existing "HELP" lines to do this? In the wheel files, you could have a list of all matching tires, and in the tire files, you could have a list of matching wheels.
e.g.:
Tire File:
!HELP Matching Wheels: 12345.dat, 54321.dat ...

Wheel Files:
!HELP Matching Tires: 56789.dat, 98765.dat ...

This would give you the information you need, in the files you need them in, without clutting up the library with more parts.


Or, you could always do like I do and create a highly custom parts.lst file and put all the matching wheels and tires together for easy usage.

[Steffen]

Actually, there are not so many wheel+tyre combinations.
I find these assemblies quite a natural thing to have in the library.
For example, in my real LEGO collection I usually don't disassemble them.
I have 2 points against your suggestion of the !HELP line:
(a) It is abusing a free-text syntax element and assigns special meaning to it.
If something like that really should be our solution to this question, then we should
add a unique meta statement for that purpose.
(b) In case we did that, we would be re-creating something new which is already there:
assemblies of wheels+tyre. These can perfectly well be modeled with the syntax elements
we already have.
I would say that 20 or something of these assemblies wouldn't hurt our library.
I would see them as a win.
The reason to have them is:
(i) it is very tedious and a quite numb task to find the fitting tyres for each wheel again and again
(ii) nearly every assembly containing a wheel plus tyre would anyway create a submodel of them two,
so having that readily combined in the library saves the users from that
(iii) some wheels or tyres have slightly but wrong offsets, like 44772.dat, a big wheel with an offset misplaced by 3 in Z direction.
all these little oddities can carefully be taken care of by the wheel+tyre assemblies readily, like I for example did with 44772c01

[Michael Heidemann]

I like the idea of Steffen and he is complete right with all arguments.

To have the necessary information in one file is in my eyes a perfect solution.

The only concern that I have is a good naming scheme. I can not see anything about such a scheme here.