"normal" vs. "Mursten" vs. "Minitalia"

"normal" vs. "Mursten" vs. "Minitalia"
#1
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?
Re: "normal" vs. "Mursten" vs. "Minitalia"
#2
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.
Chris (LDraw Parts Library Admin)
Re: "normal" vs. "Mursten" vs. "Minitalia"
#3
Lol, MaUeRSTEiN...
Re: "normal" vs. "Mursten" vs. "Minitalia"
#4
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
Re: "normal" vs. "Mursten" vs. "Minitalia"
#5
here you can hear how it is pronounced in Danish, thanks to Google Translate:

http://translate.google.com/translate_tt...&q=mursten
Re: "normal" vs. "Mursten" vs. "Minitalia"
#6
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.
Re: "normal" vs. "Mursten" vs. "Minitalia"
#7
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?
Chris (LDraw Parts Library Admin)
Re: "normal" vs. "Mursten" vs. "Minitalia"
#8
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

Re: "normal" vs. "Mursten" vs. "Minitalia"
#9
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
Re: "normal" vs. "Mursten" vs. "Minitalia"
#10
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.
Re: "normal" vs. "Mursten" vs. "Minitalia"
#11
Agreed. LEGO seems to be in short supply of 5 digits design number and has started to use numbers in "older" ranges. Maybe they will even reuse 3/4 digits numbers?
Re: "normal" vs. "Mursten" vs. "Minitalia"
#12
AGGGH!!
Chris (LDraw Parts Library Admin)
Re: "normal" vs. "Mursten" vs. "Minitalia"
#13
WTF 8-//
Re: "normal" vs. "Mursten" vs. "Minitalia"
#14
Steffen Wrote: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 would suggest using an "m" PREFIX. x and u (and presumedly v, w, etc. if you ever needed them) would be the unknown values, "m" would be "mini".

Since these are unknown (and it's very unlikely that the 2x4 was numbered 3001), then the m prefix becomes "mini unknown". If/when we ever find the design IDs for these (and don't laugh, there are literally thousands of numbers Steve Bliss used to tell me we'd "never have," and now we do), they can then be folded into the official codes, the same as a u or x (but they're also kept neatly separated).

-- joshua
Re: "normal" vs. "Mursten" vs. "Minitalia"
#15
Sorry, Joshua, we should have updated the thread here.
A decision on this already has happened on the PT.
We use u....dat number for all parts of which we do not know the official part number,
this includes Minitalia
http://www.ldraw.org/cgi-bin/ptscan.cgi?q=minitalia
, Mursten:
http://www.ldraw.org/cgi-bin/ptscan.cgi?q=mursten
, and early mouldings of parts with a different underside:
http://www.ldraw.org/cgi-bin/ptscan.cgi?...+studholes

The renumbering has happened already for all except Mursten.
Re: "normal" vs. "Mursten" vs. "Minitalia"
#16
I knew they were doing it for sets but didn't realise it had extended to parts. That is worrying (to say the least). Perhaps a R suffix (or similar) for 'reuse'.

Tim
Re: "normal" vs. "Mursten" vs. "Minitalia"
#17
Tim Gould Wrote:I knew they were doing it for sets but didn't realise it had extended to parts. That is worrying (to say the least). Perhaps a R suffix (or similar) for 'reuse'.

Tim

So far, it seems the re-use has been (likely) from parts that were not released. I think I've so far discovered only one true re-use where the two parts were really well known/used. And it was for an assembly anyway, which LDRAW doesn't track in the same way as TLG. Since both patterns and assemblies are handled so much differently, the risk to LDRAW is at least lessened quite a bit.

This is a really good reason to consider tracking item IDs instead of design IDs, which is how TLG avoids conflicts (it helps with the a-b-c issue as well), and it's how I track parts as well. Currently, my %LDRAWDIR%/parts directory contains about 7000 parts, while my items/ augmentation is 32K+ parts.
Re: "normal" vs. "Mursten" vs. "Minitalia"
#18
Steffen Wrote:Sorry, Joshua, we should have updated the thread here.
A decision on this already has happened on the PT.
We use u....dat number for all parts of which we do not know the official part number,
this includes Minitalia
http://www.ldraw.org/cgi-bin/ptscan.cgi?q=minitalia
, Mursten:
http://www.ldraw.org/cgi-bin/ptscan.cgi?q=mursten
, and early mouldings of parts with a different underside:
http://www.ldraw.org/cgi-bin/ptscan.cgi?...+studholes

The renumbering has happened already for all except Mursten.

It's the same thing, the 'm' just would have segregated the parts better (and helped with the issue of how the parts might be differentiated).

I'm pretty experienced at this (the "c" syntax was something I helped drive to compromise), but I don't always "win," so it's all fine.
Re: "normal" vs. "Mursten" vs. "Minitalia"
#19
I'm surprised they're doing it for parts at all. I know the reason they chose to reuse 4 digit set number is that they look better on the boxes. Which is why S@H exclusives can use 5+ digits. Part numbers (mould ids) aren't an issue since they're mostly for internal use.

Tim
Re: "normal" vs. "Mursten" vs. "Minitalia"
#20
Thanks for this. Just FYI, the reason I avoided introducing an "m" prefix is that some third-party manufactured (MindStorms) parts are already known by LEGO with an "ms" prefix. See ms1034, et. seq. in the official library.
Chris (LDraw Parts Library Admin)
Re: "normal" vs. "Mursten" vs. "Minitalia"
#21
I agree with Cris that we should be very careful in giving more letters (like "p" for "pattern") special meanings.
Using the u........dat here is the best we can do IMHO. A good decision.
Re: "normal" vs. "Mursten" vs. "Minitalia"
#22
we already have a strategy for re-used part numbers:
suffixes a, b, c, d, e, f, ...
IMHO we should _not_ add a second, different strategy like a trailing "r" or something.
Keep the one existing strategy, please.
Everything else would just create confusion and will not make things better!
Re: "normal" vs. "Mursten" vs. "Minitalia"
#23
Tim Gould Wrote:I'm surprised they're doing it for parts at all. I know the reason they chose to reuse 4 digit set number is that they look better on the boxes. Which is why S@H exclusives can use 5+ digits. Part numbers (mould ids) aren't an issue since they're mostly for internal use.

Tim

Well, as I said, they've so far only done so for 7xxxx numbers (assemblies), design IDs that never should up in moulds anyway.

-- joshua
Re: "normal" vs. "Mursten" vs. "Minitalia"
#24
Steffen Wrote:we already have a strategy for re-used part numbers:
suffixes a, b, c, d, e, f, ...
IMHO we should _not_ add a second, different strategy like a trailing "r" or something.
Keep the one existing strategy, please.
Everything else would just create confusion and will not make things better!

Those letters are for changes to a mould over time, so a part might have a subtle difference from one time period to another (admittedly, sometimes they ARE used to correct bad initial numberings, but that's meant to be an exception).

This issue is having an entirely different design for the same number (a number long abandoned).

If an 'r' were used, it would make far more sense to use it like the 'c' portion, where more information would follow the 'r', so the r were the start of a suffix, not the entire suffix. Not that I'm advocating the 'r' approach, just trying to clarify the situation here...

-- joshua
Re: "normal" vs. "Mursten" vs. "Minitalia"
#25
Could you please clarify with an example?
Chris (LDraw Parts Library Admin)
Re: "normal" vs. "Mursten" vs. "Minitalia"
#26
Chris Dee Wrote:Could you please clarify with an example?

The r usage I'm talking about, or an example of a changed/reused number?

I'll presume the latter...

70052 is a number that should have been used in 1980, and would be an assembly, from the 7xxxx numbering.

It is now a 2012-introduced part, part 47753 in Sand Yellow, with a decoration. Back in the day, its design ID would have been 8xxxx (though those were exhausted awhile ago as well) because it's decorated.

The closest numbers I have from 1980 are
70048 BUILDING INSTRUCTION, 6000
and
70067 REMOTE CONTROL FOR DECOUPLING UNIT

Have we lost anything? Well, we don't have a whole range of values before and after the '52', and of course if it had been used in LDRAW, chances are it would have been a c (combo) part because it was likely an assembly (like the remote control).

My guess is that 70052 was never a released part. The next one in line that I know of is 70147 (nearest known design IDs to that that I know of are 70098 and 70158). 70147 is ALSO a decorated 47753.

Now if parts were tracked officially in LDRAW, then item 70052 would be the part from 1980 (design ID 70052), and item 4653511 would be the part from 2012 (design ID 70052). No conflict.

I'm simplifying, but you should be able to get the gist.

-- joshua
more detailed parts evolution history, e.g. Mursten
#27
Re: "normal" vs. "Mursten" vs. "Minitalia"
#28
The final decision was to use "dedicated" ranges of uNNNN numbers:
• u80NN for Mursten parts
• u81NN for Minitalia parts
• u82NN for Waffle plates
Chris (LDraw Parts Library Admin)
Lower ranges of design numbers for new parts
#29
Looks like LEGO has really started the reuse of lower numbers, fortunately > 10000: http://technicbricks.blogspot.fr/2012/05...eased.html
Re: Lower ranges of design numbers for new parts
#30
so what will be our strategy to deal with them?
I suggest using a, b, c, d, e suffixes as usual.
That's the currently rolled out standard.
« Next Oldest | Next Newest »

Forum Jump:

Users browsing this thread: 1 Guest(s)