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.
The tread list in the old parts request topic was getting way too big. I've created a now Part Request forum while Chris Dee works on a parts requestor system. I moved the old part request thread there and split it based on the top level threads in the tree.
G'day, I'm new to doing instructions, Ive made the truck and it shows correctly in Mlcad with all the parts synthised. However when i open up LPub it does not show the nxt cables, the rubber band and the segments for the 8.5 flexible hose (in the parts box) can any one help with what to do to get these to show in LPub. They show with povray also when you use ldlite as the preferred renderer it still does not work. I've attached what has been done so far so please dont download for your own use. It will be free access to everyone once its finished through here and moc pages.Cheers jono
Following recent discussion on changes to the parts library (specifically new leading characters for aliases and longer filenames) I've written a new version of mklist to ensure that backwards compatibility can be maintained, while also giving a little more power to the users.
Features not appearing in mklist are:
Ensure <=64 character titles using a shortening technique
Ignore parts with user supplied leading characters (eg. =, _)
Strip off leading characters (eg. ~)
Remove parts with duplicate names (experimental feature)
The code is also open source so it can easily be modified in future.
Find it here with a pre-compiled Windows executable. The code itself is exceedingly basic C++ so should compile on any OS using a gnu (or compatible) compiler with minimal changes.
I have just installed the Ldraw parts library (most recent version) and Bricksmith on my new Mac. I can open Bricksmith, and it finds the parts library. But when I open a file, it comes up with a list of "parts not found." This happens both with the sample model files that came with Bricksmith, and with .ldr files that I previously (last week) used with MLCad on my old PC. When this list is short, I can click "OK" at the bottom and the file still opens, with empty spaces for the missing pieces. When the list is long, it extends below the extent of the screen and I cannot click "OK," meaning Bricksmith is locked up and I have to go through Utilities to force it to quit.
I don't understand why Bricksmith finds the parts library, but not some of the parts. All of the parts were available when I used Ldraw with MLCad. Secondly, if I get that long list, is there a way to continue on to Bricksmith without having to force it to quit?
Is there a way to "group" Torsos (Torso + 2 Arms + 2 Hands) and Legs (Hips and 2 Legs), so LPub counts them as 1 Part (and shows them as that in the part window) instead of 5 or 2 separate parts? I tried the "group" function in MLCad without knowing what it really does but that didn't work in LPub. I don't like using shortcuts, because I want to be able to modify the parts without editing the dat. And I would have to add the modified dat to my model so others can see it.
Many issues of these already have been solved, like:
- there had been PARTS\S files which wrongly were subparts, but in fact were an assembly of screw plus pin
- putting the metal pins into separate files
etc.
Some problems are still unsolved. One very critical which currently prevents a release of these plugs is:
(A)
The geometry of plug 766a.dat is self-contradictionary.
Its center plug diameter is modeled differently than its corresponding hole.
Fixing this has a huge impact on existing official parts, as all plug sockets which can receive this plug
need updating in case the diameter is corrected at the plug.
Other current problems:
(B)
Compared with the other 2x2 lightbricks, the lightbrick 266ac01.dat has modeled its plug sockets
at a different Y position. Either this part is wrong, or all other 2x2 lightbricks.
In light of the recent discussion on 64 character limits I decided to see if I could write my own version that could shorten descriptions to unique 64 byte versions as an option. It turns out I could.
So then I added an extra feature, the ability to hide files from parts.lst based on their first character. So if you don't want colour shortcuts you can ignore them by using the description (once that's sorted).
Anyway, I've attached the source so if anyone wants to fiddle with it, and ideally try to break it. Download, rename to mklist.C and compile with no special options "$(CPP) mklist.C -o mklist.exe".
I've also compiled a version using mingw on Windows 7 but I don't know how portable it will be.
