OMR File Spec - How to handle unofficial parts

[Orion Pobursky]

I'm drafting up a new OMR File Spec for submission to the LSC. My question to you is: how do we handle unofficial parts in the model files? I see few options:
- Disallow all unofficial parts - this is undesirable for obvious reasons
- Allow unofficial parts but only those that are not already released (i.e. no fixes for official parts)
- Unrestricted use of unofficial parts.

Note that by unofficial parts I mean parts currently on the Parts Tracker and found in the ldrawunof.zip. I don't think it would be productive or desirable to allow parts that are currently not on the PT.

[Roland Melkert]

- Unrestricted use of unofficial parts.

But don't include them in the mpd or whatever (it makes them bloated, introduces duplicates), just have users install the unofficial library and release model updates when parts go from unofficial to official and have e.g. a different rotation or name.

[Tore Eriksson]

Roland Melkert Wrote:
-------------------------------------------------------
> - Unrestricted use of unofficial parts.
>
> But don't include them in the mpd or whatever (it
> makes them bloated, introduces duplicates), just
> have users install the unofficial library and
> release model updates when parts go from
> unofficial to official and have e.g. a different
> rotation or name.

I strongly disagree.

Use unofficial parts, but give them unique object names inside the MPD, like 5555_973pTintinFace.dat (where 5555 is set number)

That will allow both unofficial parts in the PT and home-made mockups. That will never cause problems with renaming part files or re-orientation.

Whenever a part goes official, the MPD is edited, the unofficial part removed and orientation of the official part reference is checked/adjusted.

/Tore

[Philippe Hurbain]

I strongly support Tore's proposal. Orion, it would be nice to add the prefix possibility to MPDWizard

[Roland Melkert]

Using prefixes would solve the dependency problem.

I still 'worry' about the size though (because i take it all primitives and sub parts have to be included as well), but taking in mind the size of harddrives these days it might be a non issue as long the mpd's get reedited/generated upon new library releases.

[Tore Eriksson]

Roland Melkert Wrote:
-------------------------------------------------------
> Using prefixes would solve the dependency
> problem.
>
> I still 'worry' about the size though (because i
> take it all primitives and sub parts have to be
> included as well), but taking in mind the size of
> harddrives these days it might be a non issue as
> long the mpd's get reedited/generated upon new
> library releases.

I think they should be reedited/regenerated upon new library releases anyway, since there never will be a final version of any LDraw model as long as parts are being "moved-to" all the time.

/Tore

[Chris Dee]

The "~Moved to" concept is there to avoid users having to regenerate thier models when we learn new information about a part's true identifier or (in rare cases) we change our minds about naming conventions. Is the size advantage you gain by in-lining "~Moved to" references worth the cost of perpetual maintenance.

It also sounds like you are arguing for less frequent parts updates - and that's the first time I have heard that.

[Tore Eriksson]

Chris Dee Wrote:
-------------------------------------------------------
> The "~Moved to" concept is there to avoid users
> having to regenerate thier models when we learn
> new information about a part's true identifier or
> (in rare cases) we change our minds about naming
> conventions. Is the size advantage you gain by
> in-lining "~Moved to" references worth the cost of
> perpetual maintenance.

I assume the last sentence is supposed to be a question. You made an incorrect assumption on why I keep updating my models with up-to-date moved-to part references. It has nothing to do with size advantage. It has to do with the fact that I still am stuck with L3Lab while working on Datsville, even though I have great hopes for finally deleting L3Lab after more than ten years of faithful service if Roland Melkert's editor in progress is as fast as he suggests. The problem with L3Lab and moved-to parts is that it generates one warning for each part that has been "moved-to... ". I wish I hadn't deleted my moved-to.log for Datsville but kept all log posts from 1999 until now, but it just went way too many megabytes large.

I would definitely not use the phrase "rare cases" here.

So, instead of pressing 'OK' 72 times for the 72 warning the latest parts update alone would have caused, I run my little DOS utility program that updates the references in the sub-models instead.

And pretty please don't tell me to use LDView instead. It takes 63.2 seconds to render town.ldr while L3Lab takes 4.634 seconds on my PC.

> It also sounds like you are arguing for less
> frequent parts updates - and that's the first time
> I have heard that.

Now that's a truly creative interpretation.