LDraw.org Discussion Forums

Are there any known programs that would load a file incorrectly if it's extension was ldr but was, in fact, a mpd? If not, I move to retire the mpd file extension and have all non-part files be .ldr

(2019-08-10, 20:53)Orion Pobursky Wrote: [ -> ]Are there any known programs that would load a file incorrectly if it's extension was ldr but was, in fact, a mpd? If not, I move to retire the mpd file extension and have all non-part files be .ldr

I agree that always using .ldr for non-parts would be good. Unfortunately, I have no idea if this causes problems in any programs.

From LPub3D side, there is no dependency on the model file extension used.

(2019-08-10, 20:53)Orion Pobursky Wrote: [ -> ]Are there any known programs that would load a file incorrectly if it's extension was ldr but was, in fact, a mpd? If not, I move to retire the mpd file extension and have all non-part files be .ldr

LDCad doesn't care about the extension, only header, content and as a fallback the location (library or not) are used.

But why would you want to retire the extension?

I don't really see an advantage, unless we drop .dat too and use .ldr for everything.

(2019-08-12, 18:08)Roland Melkert Wrote: [ -> ]LDCad doesn't care about the extension, only header, content and as a fallback the location (library or not) are used.

But why would you want to retire the extension?

I don't really see an advantage, unless we drop .dat too and use .ldr for everything.

Because it's:
- Not necessary
- LDCad (and other programs) don't save the file with a MPD extension if it is an MPD
- I'm tired of the MPD vs. LDR extension argument with the OMR

The library can stay DAT since:
- We would have to recycle almost the entire library to update the type lines
- Provides a nice distinction between user edited files (LDR) and the library.

(2019-08-12, 18:39)Orion Pobursky Wrote: [ -> ]Because it's:
- Not necessary
- LDCad (and other programs) don't save the file with a MPD extension if it is an MPD
- I'm tired of the MPD vs. LDR extension argument with the OMR

The library can stay DAT since:
- We would have to recycle almost the entire library to update the type lines
- Provides a nice distinction between user edited files (LDR) and the library.

I'm fine with MPD. A quick look at the extension tells you that there will be submodels and that it is or a scene or a model say with movable subparts.

I wish LDCad had proper MPD support for import/export of submodels.

w.

(2019-08-13, 6:44)Willy Tschager Wrote: [ -> ]I wish LDCad had proper MPD support for import/export of submodels.

There are some tools, like:

reorganize/detach content (on a selection)
session/detach this subfile

but for mass conversion I suggest using mpdcenter as the selection detach isn't applied recursively.

(2019-08-13, 6:44)Willy Tschager Wrote: [ -> ]I'm fine with MPD. A quick look at the extension tells you that there will be submodels and that it is or a scene or a model say with movable subparts.

I wish LDCad had proper MPD support for import/export of submodels.

w.

+1

(2019-08-15, 20:43)Roland Melkert Wrote: [ -> ]There are some tools, like:

reorganize/detach content (on a selection)
session/detach this subfile

but for mass conversion I suggest using mpdcenter as the selection detach isn't applied recursively.

Roland,

I know this all perfectly. Honestly speaking for me it is not an option saving my work, firing up another prog just to import a submodel I used in another project.

w.

(2019-08-16, 7:16)Willy Tschager Wrote: [ -> ]I know this all perfectly. Honestly speaking for me it is not an option saving my work, firing up another prog just to import a submodel I used in another project.

Same here... the thing I miss most would be the possibility to exchange submodels (and their dependancies) between two opened models!

(2019-08-15, 20:43)Roland Melkert Wrote: [ -> ]There are some tools, like:

reorganize/detach content (on a selection)
session/detach this subfile

but for mass conversion I suggest using mpdcenter as the selection detach isn't applied recursively.

As already mentioned, I never thought I would become a diehard LDCad'er.
What has completely changed in the meantime, and I already regret that I did not change earlier.
Were probably the perfect MLCad tutorials from Willy.
I am also completely satisfied with the program. Sometimes it is just whining at a very high level.

I'm completely fine with having the mpd beside ldr and dat extension.
It shows perfectly, what is inside a model.
dat -> for parts (and subparts)
ldr -> for single models
mpd -> for models with submodels or several single models.

Therefor  I don't like the idea to retire the mpd extension.

/Max

(2019-08-17, 17:58)Max Martin Richter Wrote: [ -> ]I'm completely fine with having the mpd beside ldr and dat extension.
It shows perfectly, what is inside a model.
dat -> for parts (and subparts)
ldr -> for single models
mpd -> for models with submodels or several single models.

Therefor  I don't like the idea to retire the mpd extension.

/Max

+1...

I'm going to go on record stating that I totally disagree with all of these claims that knowing that a model is "multi-part" has any value at all to the average user. A model is a model is a model. Whether or not the author of that model chose to split it up into sub-models has absolutely no bearing on what it is. And any MPD can of course be flattened, which results in a model that is indistinguishable to the end user, but very different internally. Confusing users by having two separate file extensions for "ldraw models" is, in my opinion, a bad thing.

You have a point...

(2019-08-17, 22:03)Travis Cobbs Wrote: [ -> ]I'm going to go on record stating that I totally disagree with all of these claims that knowing that a model is "multi-part" has any value at all to the average user. A model is a model is a model. Whether or not the author of that model chose to split it up into sub-models has absolutely no bearing on what it is. And any MPD can of course be flattened, which results in a model that is indistinguishable to the end user, but very different internally. Confusing users by having two separate file extensions for "ldraw models" is, in my opinion, a bad thing.

I'd like to revive this discussion. Everything Travis write above I agree with. I'll go one step further in saying unless someone can come up with a really good reason why we shouldn't retire mpd, then we should. There will be less confusion going forward (LDCad and Bricksmith all ready save mpd files as ldr by default) and existing mpd files will still work.

(2019-09-23, 17:14)Orion Pobursky Wrote: [ -> ]I'd like to revive this discussion. Everything Travis write above I agree with. I'll go one step further in saying unless someone can come up with a really good reason why we shouldn't retire mpd, then we should. There will be less confusion going forward (LDCad and Bricksmith all ready save mpd files as ldr by default) and existing mpd files will still work.

It would make life easier for me as I do not have to arbitrarily decide when a file is an LDR and when it is an MPD. It can still be handles as a legacy format, like old Excel formats and such - only the conversion is trivial here.

(2019-09-23, 17:14)Orion Pobursky Wrote: [ -> ]There will be less confusion going forward (LDCad and Bricksmith all ready save mpd files as ldr by default) and existing mpd files will still work.

LDCad saves as mpd if the current (new) model has submodels, otherwise it will save new files as ldr.

I could remove that from the upcoming 1.6d to let it always save as ldr, or make it an option.

(2019-09-23, 17:41)Roland Melkert Wrote: [ -> ] the upcoming 1.6d

1.6d ??? What happend to that 2.0 project with the new GUI? (Addmidately the new themes posted the other day are a giant leap forward). I still have plans to rewrite the MLCad tutorials for LDCad, but ... but only if ... you know how much I hate your menus.

w.

(2019-09-23, 18:43)Willy Tschager Wrote: [ -> ]1.6d ??? What happend to that 2.0 project with the new GUI? (Addmidately the new themes posted the other day are a giant leap forward). I still have plans to rewrite the MLCad tutorials for LDCad, but ... but only if ... you know how much I hate your menus.

w.

https://forums.ldraw.org/thread-23672-po...l#pid34043

(2019-09-23, 18:43)Willy Tschager Wrote: [ -> ]1.6d ??? What happend to that 2.0 project

I still do bug fixes and snap info for the 1.6 branch. Hoping to get the 2.0 project back on track when my work projects are less demanding.

(2019-08-10, 20:53)Orion Pobursky Wrote: [ -> ]Are there any known programs that would load a file incorrectly if it's extension was ldr but was, in fact, a mpd? If not, I move to retire the mpd file extension and have all non-part files be .ldr

In light of this thread:
https://forums.ldraw.org/thread-24589-po...l#pid41128

I'd like to renew my call to retire the MPD extension and to go LDR only for model files. All software that claims to be LDraw compliant should implement the MPD spec and there is functionally not difference between the two. Since it clear that at least some users are confused, I'd like to simplify things.

(2021-04-29, 4:04)Orion Pobursky Wrote: [ -> ]I'd like to simplify things.

If it ain't broke, don't fix it.

(2021-04-29, 4:04)Orion Pobursky Wrote: [ -> ]In light of this thread:
https://forums.ldraw.org/thread-24589-po...l#pid41128

I'd like to renew my call to retire the MPD extension and to go LDR only for model files. All software that claims to be LDraw compliant should implement the MPD spec and there is functionally not difference between the two. Since it clear that at least some users are confused, I'd like to simplify things.

I agree (as probably would be expected based on my posts above), with the caveat that we need to make sure all LDraw programs still recognize the MPD extension, just not create new files with that extension. So, I don't think "retire the MPD extension" is the best way to word things.

(2021-04-29, 19:22)Magnus Forsberg Wrote: [ -> ]If it ain't broke, don't fix it.

My point is that it is broke as it is causing confusion.

(2021-04-29, 4:04)Orion Pobursky Wrote: [ -> ]In light of this thread:
https://forums.ldraw.org/thread-24589-po...l#pid41128

I'd like to renew my call to retire the MPD extension and to go LDR only for model files. All software that claims to be LDraw compliant should implement the MPD spec and there is functionally not difference between the two. Since it clear that at least some users are confused, I'd like to simplify things.

If my understanding is complete, the reason to keep .mpd is that it tells the user at a glance something about the content of the file—i.e., that it contains submodels, or more specifically, subfiles, as reflected by the format's only metas (0 FILE and 0 NOFILE).

Is there a way to readily convey this information to the user other than by way of the .mpd extension?

Are there any other affirmative reasons to keep .mpd? (By that I mean reasons that specifically require keeping it, as opposed to reasons not to retire it.)

(2021-04-29, 21:04)N. W. Perry Wrote: [ -> ]If my understanding is complete, the reason to keep .mpd is that it tells the user at a glance something about the content of the file—i.e., that it contains submodels, or more specifically, subfiles, as reflected by the format's only metas (0 FILE and 0 NOFILE).

Is there a way to readily convey this information to the user other than by way of the .mpd extension?

Are there any other affirmative reasons to keep .mpd? (By that I mean reasons that specifically require keeping it, as opposed to reasons not to retire it.)

I will repeat. What difference does it make to the end-user if the file contains embedded sub-models? I don't consider this to be a factor at all.

(2021-04-29, 22:02)Travis Cobbs Wrote: [ -> ]I will repeat. What difference does it make to the end-user if the file contains embedded sub-models? I don't consider this to be a factor at all.

That I don't offer a perspective on, I'm only reporting on what I understand the given reason to be. Do I have it wrong?

(2021-04-29, 4:04)Orion Pobursky Wrote: [ -> ]I'd like to renew my call to retire the MPD extension and to go LDR only for model files.

I don't really care one way or the other, but if we do this it will indirectly solve another discussion.

Namely "can a model reference a mpd?", if all files are 'the same' this should be allowed by default.

Making the LDraw format the truly recursive format I always thought it was (I'm not sure anymore due to the late search order discussion though.).

(2021-04-29, 4:04)Orion Pobursky Wrote: [ -> ]In light of this thread:
https://forums.ldraw.org/thread-24589-po...l#pid41128

I'd like to renew my call to retire the MPD extension and to go LDR only for model files. All software that claims to be LDraw compliant should implement the MPD spec and there is functionally not difference between the two. Since it clear that at least some users are confused, I'd like to simplify things.

If I remember correctly there was confusion among the casual user that a ldr file could not only contain dat files, so parts, but also other ldr files called submodels. From an organisational point of view it should be handled like this:

dat - parts
ldr - single model
mpd - multiple models

w.

(2021-04-30, 5:59)Willy Tschager Wrote: [ -> ]If I remember correctly there was confusion among the casual user that a ldr file could not only contain dat files, so parts, but also other ldr files called submodels. From an organisational point of view it should be handled like this:

dat - parts
ldr - single model
mpd - multiple models

w.

Our customer is not the handful of people who regularly post here on the forum. Our customer is the casual user who never even looks at the forum. The fact that Weber had a few question this matter hints at a larger issue. From their standpoint the difference is confusing especially since Some programs don't save with the MPD extension by default. 

Confusion is bad. Simplification is good.

(2021-04-30, 5:59)Willy Tschager Wrote: [ -> ]If I remember correctly there was confusion among the casual user that a ldr file could not only contain dat files, so parts, but also other ldr files called submodels. From an organisational point of view it should be handled like this:

dat - parts
ldr - single model
mpd - multiple models

w.

And of course parts contain other parts, but they do it by referencing other files according to an expected file structure. I suppose if submodels were referenced the same way without needing to inline them, that would obviate the need for the mpd format.

(2021-04-30, 13:24)N. W. Perry Wrote: [ -> ]That would obviate the need for the mpd format.

I'd just like to clarify: I'm not suggesting getting rid of the MPD format (that definitely needs to stay), I'm suggesting that we stop using the mpd file extension in an official capacity.

(2021-04-30, 13:50)Orion Pobursky Wrote: [ -> ]I'd just like to clarify: I'm not suggesting getting rid of the MPD format (that definitely needs to stay), I'm suggesting that we stop using the mpd file extension in an official capacity.

Yes, right. From my perspective it's all one format anyway—dat, ldr, mpd or whatever.

So, there'd be nothing to prevent users who do find value in the mpd extension from continuing to use it (as long as their favorite programs continue to recognize it)?

Exactly. The mpd extension isn't going away nor will it be wrong to use it. Rather, LDraw.org will only recommend using DAT (for library files) and LDR (for everything else).

(2021-04-30, 15:19)Orion Pobursky Wrote: [ -> ]Exactly. The mpd extension isn't going away nor will it be wrong to use it. Rather, LDraw.org will only recommend using DAT (for library files) and LDR (for everything else).

Good thing. There are so many tutorials and tools using "mpd" that banning completely mpd extension would just replace one confusion with another...

(2021-04-30, 15:47)Philippe Hurbain Wrote: [ -> ]Good thing. There are so many tutorials and tools using "mpd" that banning completely mpd extension would just replace one confusion with another...

And we can't control those sites. Ive never said "ban" and if I implied it that was not my intent. Much like when we recommended LDR and programs continued to use DAT for awhile and there are still model files out there with DAT (including in my own archives), this would be a gradual change. Hence the word "retire".

(2021-04-30, 15:19)Orion Pobursky Wrote: [ -> ]Exactly. The mpd extension isn't going away nor will it be wrong to use it. Rather, LDraw.org will only recommend using DAT (for library files) and LDR (for everything else).

Then it sounds like it would be fine either way. The only practical effect I can see is having to change the OMR spec to allow .mpd, but require only .ldr.

(2021-04-30, 21:28)N. W. Perry Wrote: [ -> ]Then it sounds like it would be fine either way. The only practical effect I can see is having to change the OMR spec to allow .mpd, but require only .ldr.

OMR is easy since I can change everything with a script on the server.

(2021-04-30, 5:59)Willy Tschager Wrote: [ -> ]If I remember correctly there was confusion among the casual user that a ldr file could not only contain dat files, so parts, but also other ldr files called submodels. From an organisational point of view it should be handled like this:

dat - parts
ldr - single model
mpd - multiple models

w.

Don't forget XMPD! Meaning, an LDR file should be able to contain parts, submodels, and multimodels. For organizing large multi-user projects this is critical!

But as long as the format is recursive and can later be "unpacked" to however the designers originally intended the models to be it doesn't matter what the extension is.