LDraw.org Discussion Forums

Full Version: Wheel+Tyre Shortcuts: to have or not to have?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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.
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.
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.
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.
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.
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.
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
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.
Pages: 1 2