OMR specification and unofficial files

[Philippe Hurbain]

Following the problem mentionned here and after discussions with Mikeheide about MPDCenter, I think that OMR specifications should be updated to make it clear that unofficial parts MUST be included in OMR conform files.
It is more or less implied by this paragraph of the specification but it should be made much more explicit

Unofficial parts are allowed to be used. The filename of the unofficial part is subject to the following naming rules:

<Set Number>[-<Optional Qualifier>] - <Unofficial Part Number>.dat

Where:
<Set Number> is the the number printed on the model's container.
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>.
<Unofficial Part Number> is the unofficial part number assigned in that very moment.

Example:
33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.dat.

[Willy Tschager]

Following the problem mentionned here and after discussions with Mikeheide about MPDCenter, I think that OMR specifications should be updated to make it clear that unofficial parts MUST be included in OMR conform files.
It is more or less implied by this paragraph of the specification but it should be made much more explicit

Unofficial parts are allowed to be used. The filename of the unofficial part is subject to the following naming rules:

<Set Number>[-<Optional Qualifier>] - <Unofficial Part Number>.dat

Where:
<Set Number> is the the number printed on the model's container.
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>.
<Unofficial Part Number> is the unofficial part number assigned in that very moment.

Example:
33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.dat.

How about?

Unofficial parts are allowed to be used. The filename of the unofficial part is subject to must respect the following naming rules:

<Set Number>[-<Optional Qualifier>] - <Unofficial Part Number>.dat

Where:
<Set Number> is the the number printed on the model's container.
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>.
<Unofficial Part Number> is the unofficial part number assigned in that very moment.

Example:
33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.dat.

w.

[Philippe Hurbain]

I'd be even more explicit:

Unofficial parts are allowed to be used, in this case they must be included in the MPD. The filename of the unofficial part is subject to must respect the following naming rules:

...or something like that!

[Michael Heidemann]

Unofficial parts are allowed to be used in models and must be included in the mpd-file in that case. The filenam.......

The first sentence is the relevant sentence. In the todays specification the integration of unofficial files in the mpd-file is not explicid needed.

[Willy Tschager]

Unofficial parts are allowed to be used, but must be included in the MPD as subfiles. The filename of the unofficial part is subject to the following naming rules:

[Philippe Hurbain]

Fine for me!

[Michael Heidemann]

I like this and are going to implement this change into MPDCenter.

[Michael Heidemann]

There is nothing to do because the current MPDCenter already cares about the unofficial parts.

http://forums.ldraw.org/showthread.php?t...7#pid18367

[Damien Roux]

I have actually missed that thread but as I'm reworking my sets to make them OMR compliant, I'd like to express my point of view on this inlining of unofficial parts :


I personally don't like that at all. For several reasons :
I would not be able to use a LGEO equivalent for rendering a part if it is defined like that (this is my main concern).
I don't like to have anything which is not a part in my sets.
Ldview will simply download the part if it is missing.
If the part is changing on the tracker, it will never show up in the model.
Imagine the origin is changing, it quite easy to see and to update. Same if name is changing.
I am 100% sure OMR repository models will not be updated to remove the inlined part when it will be official.

I have the feeling that this rule has been made for only a few particular cases. I am pretty sure more than 90% of unofficial parts become official without a name change and a origin redefinition.
A lot of unofficial parts inlcuded on my sets are patterned parts I submit to the tracker before building the set. As for me there is no reason to inline those parts as the origin won't change, and rarely the name, even if the name changes all viewers will give an error and point this out.


The two points of view have pros and cons. But I think there is much more cons in inlining the part than there are pros, at least for a render guy as me.

Could you express on that?

Maybe, I have a suggestion:
What about two status: OMR compliant with/without unofficial parts.
It could be much easier to check when parts become available (just a quick open in ldview to see if everything is still OK) than with an inlined part that no one is aware about.

[Travis Cobbs]

I don't understand why LGEO-type replacements wouldn't work for unofficial files included in the MPD. I'm pretty sure LDView will happily do that, as long as the included part has the unofficial part meta-statement.
Changing origins is one of the main reasons that this is required. We don't want models in the OMR to suddenly stop working because the unofficial part's origin was changed. With the file baked in, the model will continue to look correct indefinitely.

[Philippe Hurbain]

I am 100% sure OMR repository models will not be updated to remove the inlined part when it will be official.

That's not a huge problem, at least it remains correct...

If the part is changing on the tracker, it will never show up in the model.
Imagine the origin is changing, it quite easy to see and to update. Same if name is changing.

Using your own argument: "I am 100% sure OMR repository models will not be updated" means that files that are not self contained or using the trusted official library will get broken. I have too often seen models on the net that were useless because the virtual builder didn't care to include unofficial parts!

I don't understand why LGEO-type replacements wouldn't work for unofficial files included in the MPD. I'm pretty sure LDView will happily do that, as long as the included part has the unofficial part meta-statement.

Unfortunately parts inside OMR files get renamed as <setname><part number>.dat. This means that correspondance with LGEO parts is not so direct.

[Damien Roux]

That's not a huge problem, at least it remains correct...

I would not say "correct", it would remain wrong but the MPD file will be viewable.

Using your own argument: "I am 100% sure OMR repository models will not be updated" means that files that are not self contained or using the trusted official library will get broken. I have too often seen models on the net that were useless because the virtual builder didn't care to include unofficial parts!

I personnaly prefer to have a broken model, so that it can be pointed out by any user noticing it and corrected instead of a model with parts outdated and hard to detect. (But maybe it's because I'm an "advanced" ldraw user).

I have too often seen models on the net that were useless because the virtual builder didn't care to include unofficial parts!

I'm not sure the average virtual builder is even aware of those specifications, models out of the OMR (like in Eurobicks) will keep on not included unofficial parts. The uselessness of a "broken" model is a matter of what one want to do with it. If I download a model with an included part, It's useless for me.

Unfortunately parts inside OMR files get renamed as <setname><part number>.dat. This means that correspondance with LGEO parts is not so direct.

As I said, this my main concern, and I don't want to include unofficial parts because of that.
I guess it would be the same for any people who has written scripts to export ldraw Model to other softwares.
And even if ldview can replace a self-contained part by its LGEO equivalent, if the origin has changed, it will be the render which will be broken.



I don't want to make a mess, only to give my point of view.

In a ideal world, the OMR would be linked to the tracker, and as with parts that cannot be certified if a sub-part is not, a set would not be certified if one part is not.

[Philippe Hurbain]

Definitely I don't agree. A published model should be usable as such. I remember struggling for hours to find again parts in a model I wanted to build, as these parts were renamed and their history lost. Origin change is less of a problem, but can be tricky sometimes. At least if you can see the part you know what it is, and if a better version is available you can update it.

I'm not sure the average virtual builder is even aware of those specifications, models out of the OMR (like in Eurobicks) will keep on not included unofficial parts.

And that's a shame. It's so easy and so useful... I know it's a lost cause, but everytime I see discussions telling "Can't build this model because this part is missing" I insist on useage of MPDcenter or MPDwizard to include unofficial parts!

[Damien Roux]

Well, I guess, I will need to deal with that as I really want to participate in the OMR...

But I must keep on using mdp with unofficial parts not included for rendering purpose. I will have two files, one for me, one for the OMR.


But, it would be really useful that each official release of parts come with a list of OMR sets to update, so we can keep control of them. It can be easy to parse the MPD files and see if a part has become official using its name. But if the name has changed, how to detect it?

Maybe it can also be good the make a difference between OMR with unofficial parts and OMR without unofficial parts.
So that people who want to work on updating the OMR can easily detect it.

[Merlijn Wissink]

I was actually thinking about making a little piece of software that (when there is a parts update) scans ALL omr files to detect inlined parts that are official. Or is MPDcenter maybe able to do that (I never used it with more than 1 .mpd file)?

Also, regarding the discussion: I agree with you on every point. However, I also agree with all arguments that favor inlining the parts. In the end, it doesn't matter a lot to me personally and I'm happy either way. But, since I'm not the 'admin' of the OMR models, I have to follow the rules as they are of course

[Michael Heidemann]

to detect inlined parts that are official. Or is MPDcenter maybe able to do that

That is one of the lot build in functions of MPDCenter :-)

I like to give my 0.50 cent to this discussion:
1) unofficial models may change in ANY way !
2) using unofficial files is up to the author of a model, so he needs to care about his model.
3) The omr is "build" under the name of LDraw and we need to care about the "official" models.
4) The only way to fix this under one rule is including (not inlining) the unofficial parts used in a model.

I like rendered pictures made with lgeo parts very much, but all the things LDraw make official are not POV-Ray related.
So it is up to you to accept the rules (compromises) we made for the majority of users for the omr.

Did you try MPDCenter already? Do you missing any feature?
I am open for improvements :-)

[Merlijn Wissink]

Well, I know it can remove parts inside an .mpd file dat have become official (I've done that a lot for the models I've added the new OMR website that came from the old omr .zip file).

But what I'm looking for (when parts update 2016-01 arrives) is a way to bulk proces a lot of .mpd files. So, I just download the complete omr collection and run it through some software (e.g. MPDCenter) which then scans through the models to remove included parts that now have an official version. and creates a list of the changed files (so I can upload them again).

As of now, I can't really find a way to bulk open and process a lot of .mpd files (which are located in a tree of folders). Aside from that, I wonder if it's even 'possible' to scan through hundreds of files in 1 operation

[Damien Roux]

Of course I will accept the rules, but I just though there was room for discussion.

And you said ldraw is not making official things related to pov ray. But LGEO and PovRay rendering stuff is included into the AIOI, so it should at least be taken into consideration.

BTW I have some remarks on MPDcenter. I'll make a post in the appropriate section about it later.

[Willy Tschager]

I'd like to add the following as example of an OMR file to the OMR specs. Any objections?

Code:

0 FILE 6712 - Main.ldr
0 Main
0 Name: 6712 - Main.ldr
0 Author: Willy Tschager [Holly-Wood]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

1 0 0 0 0 1 0 0 0 1 0 0 0 1 6712 - Fireplace.ldr
1 0 -140 -49 -32 0.5 0 -0.866 0 1 0 0.866 0 0.5 6712 - Horse.ldr
1 0 -140.866 -129 -31.5 0.5 0 -0.866 0 1 0 0.866 0 0.5 6712 - Sheriff.ldr
1 0 83 -99 64 1 0 0 0 1 0 0 0 1 6712 - Bandit.ldr
1 6 81 3 76 1 0 0 0 1 0 0 0 1 30139.dat
1 2 -51 8 86 1 0 0 0 1 0 0 0 1 6064.dat
1 7 80 0 -14 0.707 0 0.707 0 1 0 -0.707 0 0.707 3069bp03.dat

0 FILE 6712 - Horse.ldr
0 Horse
0 Name: 6712 - Horse.ldr
0 Author: Willy Tschager [Holly-Wood]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

1 0 0 0 0 1 0 0 0 1 0 0 0 1 4493c01.dat
1 6 0 -8 0 1 0 0 0 1 0 0 0 1 4491b.dat
1 7 -31 -44 27 1 0 0 0 0 -1 0 1 0 30141.dat

0 FILE 6712 - Fireplace.ldr
0 Fireplace
0 Name: 6712 - Fireplace.ldr
0 Author: Willy Tschager [Holly-Wood]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

1 7 0 0 0 1 0 0 0 1 0 0 0 1 3031.dat
0 STEP
1 0 -30 -8 10 0 0 -1 0 1 0 1 0 0 2555.dat
1 0 -30 -8 -10 0 0 -1 0 1 0 1 0 0 2555.dat
0 STEP
1 0 0 -8 -10 1 0 0 0 1 0 0 0 1 2412b.dat
1 0 0 -8 10 1 0 0 0 1 0 0 0 1 2412b.dat
0 STEP
1 38 -24 -14 -10 0 0 1 0 -1 0 1 0 0 6126a.dat
1 38 -24 -14 10 0 0 1 0 -1 0 1 0 0 6126a.dat
1 0 0 -28 -2 -0.966 0 0.259 0 1 0 -0.259 0 -0.966 4528.dat

0 FILE 6712 - Sheriff.ldr
0 Sheriff
0 Name: 6712 - Sheriff.ldr
0 Author: Willy Tschager [Holly-Wood]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

1 7 0 -24 0 1 0 0 0 1 0 0 0 1 3629pw2.dat
1 14 0 -24 0 1 0 0 0 1 0 0 0 1 3626bp35.dat
1 7 0 0 0 1 0 0 0 1 0 0 0 1 973pw4.dat
1 0 0 32 0 1 0 0 0 1 0 0 0 1 3815.dat
1 7 -15.552 9 0 0.985 -0.128 -0.112 0.17 0.743 0.646 0 -0.656 0.755 3818.dat
1 7 15.552 9 0 0.985 0.139 0.098 -0.17 0.807 0.565 0 -0.574 0.819 3819.dat
1 0 -21.93 15.393 -20.098 0.995 -0.066 0.069 0.066 0.997 0.007 -0.07 -0.002 0.997 3820.dat
1 0 22.28 17.422 -19.215 0.985 0.167 -0.03 -0.17 0.97 -0.171 0 0.174 0.985 3820.dat
1 0 0 44 0 1 0 0 0 1 0 0 0 1 3816.dat
1 0 0 44 0 1 0 0 0 1 0 0 0 1 3817.dat
1 7 -22.656 13.187 -30.096 0.998 -0.052 0.033 0.058 0.975 -0.213 -0.021 0.214 0.976 30132.dat

0 FILE 6712 - Bandit.ldr
0 Bandit
0 Name: 6712 - Bandit.ldr
0 Author: Willy Tschager [Holly-Wood]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

1 6 0 -27 0 1 0 0 0 1 0 0 0 1 3629.dat
1 14 0 -27 0 1 0 0 0 1 0 0 0 1 3626bpw1.dat
1 0 0 0 0 -1 0 0 0 1 0 0 0 -1 30133.dat
1 0 0 0 0 1 0 0 0 1 0 0 0 1 973pw5.dat
1 0 0 32 0 1 0 0 0 1 0 0 0 1 3815.dat
1 0 -15.552 9 0 0.985 -0.128 -0.112 0.17 0.743 0.646 0 -0.656 0.755 3818.dat
1 0 15.552 9 0 0.985 0.139 0.098 -0.17 0.807 0.565 0 -0.574 0.819 3819.dat
1 0 -21.93 15.393 -20.098 0.135 0.99 0.012 -0.988 0.136 -0.069 -0.07 -0.002 0.997 3820.dat
1 0 22.28 17.422 -19.215 0.985 0.167 -0.03 -0.17 0.97 -0.171 0 0.174 0.985 3820.dat
1 7 22.08 16.263 -29.297 0.985 0.155 -0.069 -0.17 0.899 -0.401 0 0.407 0.913 30132.dat
1 0 0 44 0 1 0 0 0 1 0 0 0 1 3816.dat
1 0 0 44 0 1 0 0 0 1 0 0 0 1 3817.dat
1 2 -18 13 -47 0.259 -0.118 0.959 0 0.993 0.122 -0.966 -0.032 0.257 3069bpw2.dat

w.

[Philippe Hurbain]

None here. An example is always a Good Thing ™

[Max Martin Richter]

I'm fine with it.

[Willy Tschager]

Added.

w.