# LDraw.org Discussion Forums

Full Version: "normal" vs. "Mursten" vs. "Minitalia"
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
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?
I agree that this is complex, and multi-faceted, which is why I have resisted giving any of these the Admin certify which would release them into the wild.

I don't like Solution A as it gives special meaning to suffix "m". We have more than enough use-cases for single letter suiffices (part variants, on-sprue multi-part identifiers, sticker sheet qualifiers, backward compatibilty maintenance for part number errors). This would just add to the confusion.

I think the use of the regular part number (e.g. 3001) in Solution A and Solution C is very artificial, because as you suggest, the 2x4 Mursten brick probably never was 3001.

I strongly prefer Solution B, maybe with a dedicated series of uNNNN numbers for each. Or, we do have a completely unused range of numbers (1000-1999), the use of which would indicate that these parts pre-date the more controlled 2xxx, 3xxx, 4xxx numbering.

But my biggest question surrounding the inclusion of these is "What value do they add to the library?". Would someone really want to build a virtual model with the Minitalia versions of regular parts? We are then back to the "parts inventory" vs. "CAD resource" argument which is as old as LDraw itself.
Lol, MaUeRSTEiN...
Chris Dee Wrote:But my biggest question surrounding the inclusion of these is "What value do they add to the library?". Would someone really want to build a virtual model with the Minitalia versions of regular parts? We are then back to the "parts inventory" vs. "CAD resource" argument which is as old as LDraw itself.

I know that I, and other people I know, would potentially use the texture of the underside in models. In fact I now want some of those minitalia bricks for the cross underside.

So I'm definitely in favour of having them in the library as a CAD resource.

Tim
here you can hear how it is pronounced in Danish, thanks to Google Translate:

I don't see such a big difference between CAD and inventory usage of the LDRAW library.

Think of the OMR. In fact, an OMR model is just an inventory of that very set (provided that also spare parts are placed somewhere,
e.g. lying on the floor in front of the model).

And I also would like to see both Mursten and Minitalia variants in the library,
for example, someone wants to create renders of the undersides of 2x4 bricks and explain
the differences to someone else etc.pp.

Of both moulding variants, not too many parts exist, so I think the clutter danger is limited.

Following Chris' very valid arguments, I have been convinced now that maybe the u..... solution is the best,
or the one taking the number ranges Chris mentioned. I favor u...., because the other solution suggests
that we know the part numbers of these parts, which we don't.
Can we apply the same thinking to the "waffle" plates e.g. 3020a? I'm not sure we have any real evidence these were really known by the current part numbers, so should these be moved to uNNNN numbers?
yes, of course, definetely we should.
they're the same principle: a historic mould variant.

http://www.ldraw.org/cgi-bin/ptscan.cgi?q=waffle

I think that would be better. To me 'a'/'b' means a minor variant of the same part with the same functionality (a few exceptions like plate with eye) that has been revised at remoulding. I'm not sure why, but these regional variants seem to sit outside that.

Tim
definetely.

I favor the u......dat variant, because reserving some (arbitrary) number space for these parts
will block numbers unnecessarily and will suggest that we know the numbers. we don't,
and that's what the u.....dat filenames are for.
Pages: 1 2 3