Retire MPD


Retire MPD
#1
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
Reply
RE: Retire MPD
#2
(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.
Reply
RE: Retire MPD
#3
From LPub3D side, there is no dependency on the model file extension used.
Reply
RE: Retire MPD
#4
(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.
Reply
RE: Retire MPD
#5
(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.
Reply
RE: Retire MPD
#6
(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.
LEGO ergo sum
Reply
RE: Retire MPD
#7
(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.
Reply
RE: Retire MPD
#9
(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.
LEGO ergo sum
Reply
RE: Retire MPD
#10
(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!
Reply
RE: Retire MPD
#11
(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. Big Grin
I am also completely satisfied with the program. Sometimes it is just whining at a very high level.
If nothing goes right, go left.
Reply
RE: Retire MPD
#8
(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
If nothing goes right, go left.
Reply
RE: Retire MPD
#12
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
Reply
RE: Retire MPD
#13
(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...
Reply
RE: Retire MPD
#14
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.
Reply
RE: Retire MPD
#15
You have a point...
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)