LDraw.org Discussion Forums

Full Version: Retire MPD
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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!
Pages: 1 2