Hi Steffen,
I think so -- the output is just what BrickSmith natively saves.
Hrm - there's a few issues here.
- The file itself I think is an MPD file, because it contains multiple MPD parts.
- The extension is therefore definitely wrong - it should have been an .mpd file. I think BrickSmith auto-suggests .ldr in the file-save dialog box for all files, so I just didn't notice.
- My format may not match the "natural way" to store such a suggestion database. Since .mpd files aren't really meant to store suggestion/related part lists, the format was going to require some extra conventions or metas no matter what.
The format which I have so far (which allows mpd parts but does not depend on them for the structuring of the actual relationship data) was chosen to simplify editing and maintaining a suggestion file in-editor. The original format was a simple flat list for easy parsing and databasing; Roland suggested to me that if the file itself was an LDraw file then it would be easier for users to add part relationships. So the current format is designed to create a 'workspace', with one mpd sub-model containing several relationships, and each relationship containing whole sets of parents and children. The setup is pretty arbitrary - it's what I found to be straight-forward to work with and may not be usable to anyone else.
(In particular, I wanted to be able to work with whole sets of related parts on one screen and not have to change MPD sub-models for every single relationship.)
Cheers
Ben
Steffen Wrote:(a)
could you get rid of the unnecessary trailing zeros to save filesize and parsing time?
I think so -- the output is just what BrickSmith natively saves.
Quote:(b)[/quote]
using LDR as file extension instead of MPD for this contents seems wrong to me.
your contents is a list of (PARENT+CHILDREN) assemblies, and the natural way to store something like that would be MPD
, as far as I can see, because LDR is/should be/should be thought of "1 assembly", not "a list of assemblies".
to word it more abstract: LDR is "an entity", and MPD is "a list of entities". you need the list. what were the reasons to use LDR instead of MPD?
Hrm - there's a few issues here.
- The file itself I think is an MPD file, because it contains multiple MPD parts.
- The extension is therefore definitely wrong - it should have been an .mpd file. I think BrickSmith auto-suggests .ldr in the file-save dialog box for all files, so I just didn't notice.
- My format may not match the "natural way" to store such a suggestion database. Since .mpd files aren't really meant to store suggestion/related part lists, the format was going to require some extra conventions or metas no matter what.
The format which I have so far (which allows mpd parts but does not depend on them for the structuring of the actual relationship data) was chosen to simplify editing and maintaining a suggestion file in-editor. The original format was a simple flat list for easy parsing and databasing; Roland suggested to me that if the file itself was an LDraw file then it would be easier for users to add part relationships. So the current format is designed to create a 'workspace', with one mpd sub-model containing several relationships, and each relationship containing whole sets of parents and children. The setup is pretty arbitrary - it's what I found to be straight-forward to work with and may not be usable to anyone else.
(In particular, I wanted to be able to work with whole sets of related parts on one screen and not have to change MPD sub-models for every single relationship.)
Cheers
Ben