Hi all,

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)
  

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.

I'd like to use this post as a "status" info page for everybody working on the PT
regarding the review summary page of the Electric Plugs:
http://www.ldraw.org/cgi-bin/ptreviewsum...ctricplugs

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.

©
Either plug 766a.dat is too thick, or the 2x2 lightbrick has the plug socket positioned wrongly. This can be seen
at this assembly of real set 7866, where the plug collides:
1 16 0 0 0 1 0 0 0 1 0 0 0 1 4169.dat
1 0 0 -122 -1 0 0 -1 1 0 0 0 -1 0 512p01.dat
1 0 0 -122 23 1 0 0 0 0 1 0 -1 0 266bc02.dat
1 16 0 -102 10.5 1 0 0 0 0 1 0 -1 0 766ac02.dat

(D)
I currently have problems getting the thin plug (Type 1) into the existing plastic plug portion 567c04.dat :-(

Any help here, be it calipers, thoughts or advice is well appreciated.
I think the plugs may not leave without these corrections

I will update this page as a solution progresses.

Please find attached a test assembly of all the electric plugs which allows easy comparison.

Attached Files

  Electric.ldr (Size: 1.24 KB / Downloads: 0)

Hi all,

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.

Tim

Attached Files

  mklist.txt (Size: 7.69 KB / Downloads: 0)

http://www.ldraw.org/cgi-bin/ptdetail.cg.../30475.dat

Maybe someone who knows what he does can work on this part?

Hi all, I've been working on LDCad's 2D (Ortho) editing mode on and off lately, and I'm almost ready with the basic view handling. Next on the to do list is to put in special editing tools for that mode.

I already have some ideas, but at this stage I could still implement something completely different if brought to my attention.

For starters it will have mlcad's way of selection handling (always in front rectangle), everything else is still open to suggestions.

So I was wondering if anyone else has some pointers/ideas concerning working in 2D mode? Especially from the people saying they hate 'those 3D only editors'

I'd like to ask if we could drop the 64 chars par title limit, please.

Which ancient software relies on that?

The current force of this limit leads to the effect that important keywords
of the title must be abbreviated, so they cannot be grepped properly anymore,
or left out completely.

All modern software should be able to treat a first line in the file of arbitrary length, IMHO.

I'd like to ask the LSC for a drop of this limit, please.

Hey,

Here is the new LPC 1.3.4.


Please uninstall older versions of this software before installing a new version.
Your configuration won't be deleted if you have already version greater than 1.3.1 installed on your machine.

Change log:

New features:

• The program imports subfiles of primitives
  
• The projection data import now parses linetype 2 and 5
  
• DAT filenames with spaces are supported
  
• You can press the Ctrl+C/X/V or Del key to change the text displayed in on-screen textboxes
  
• It is impossible to group triangles which are adjacent to an existing group
  
• The subfile import does inline all required subparts/primitives of the subfile
  
• The highlight around a selected triangle that exactly match a template triangle is shown
  
• Vertices from projection data remain locked
  

• LPC crashes if the user sets a custom colour in the toolbar which is not defined in LDConfig.ldr
  
• LPC crashes if the user makes excessive use of the "Merge to nearest line" functions.
  
• The undo/redo functions crash the application under certain circumstances and deform a pattern.
  
• It is possible to group triangles which are adjacent to an existing group (misfeature).
  

We currently have a numbering problem on the PT, and the more I think over it, the more complicated it gets.

Can we find a solution together?

LEGO itself has produced variants of their own bricks: "Mursten" and "Minitalia".

"Mursten" predates the bricks of today. For example, the 2x4 Brick existed in several "slotted" variants, e.g.
http://www.ldraw.org/cgi-bin/ptdetail.cg...3001mc.dat
The word "Mursten" is composed of the 2 danish words "mur" (meaning "wall") and "sten" (has the same origin as "stone",
but of course means "brick" here). Thus "mur sten" are "bricks to build a wall".



"Minitalia", as I learned today, was a variant of LEGO in the 1970's, which they had created to circumvent
importing rules of Italy at that time:
http://www.lucajuventino.altervista.org/...lia_EN.htm
http://lego.wikia.com/wiki/Minitalia
http://www.brickset.com/browse/themes/?theme=Minitalia



Both variants have differences in the appearance of the parts.
No problem for us, we can model them:
http://www.ldraw.org/cgi-bin/ptscan.cgi?q=mursten
http://www.ldraw.org/cgi-bin/ptscan.cgi?q=minitalia
We already also have "Minitalia" primitives - no problem so far.

However, we currently _have_ a problem with the part numbers:

For the "mursten" variant, the current status quo on the PT is to take the "normal" part number, append an "m" and then
"something else". Example: for the normal 2x4 brick (3001.dat), the parts tracker currently carries the mursten variants
3001ma.dat
3001mb.dat
3001mc.dat
3001md.dat
3001me.dat
, cf. http://www.ldraw.org/cgi-bin/ptscan.cgi?q=3001m

But for the "minitalia" variant, just an "a" gets appended:
3001a.dat
, cf. http://www.ldraw.org/cgi-bin/ptscan.cgi?q=minitalia

That's reasonable, because the "minitalia" variant 3001a.dat in fact is just a moulding variant of the 3001.dat.
If you see it this way, things could just stay as they are now.

But on the other hand, for LEGO most probably these parts never carried the number 3001,
because both required completely separate moulds.

I now see the numberings
3001.dat
3001ma.dat
3001a.dat
clashing. The "m" for example could mean "mursten" or "minitalia". I don't understand why "mursten" gets its "m",
and "minitalia" does not.

We have several opportunities here, as
- we have u.....dat numbers
- we don't have a 8.3 filename restriction anymore.
Thus, we have several solution alternatives:

(SOLUTION A)
leave things as they are now, i.e.:
"mursten" is "normal part number plus m plus something else"
"minitalia" is "normal part number plus a,b,c,d,e, ... moulding variant suffix"

(SOLUTION B)
use separate, new u.......dat numbers for "mursten" and "minitalia" parts

(SOLUTION C)
use long filenames and make e.g.
3001.dat
3001-minitalia.dat
3001-mursten-a.dat
3001-mursten-b.dat
3001-mursten-c.dat

My problem is: each day I think this over, I favor a different solution :-(((((
solution A is very simple
solution B is very systematic
solution C is very easy to understand

what should we do?
Is there a solution D which I forgot? Which one do you favor?