2011-08-24, 13:53
Pages: 1 2
2011-08-24, 14:05
No I think Theme needs it's own META. 0 !CATEGORY is for parts and, to me, 0 !KEYWORDS is probably not needed but I kept it since I knew someone would ask.
2011-08-24, 14:17
I'm not sure a new command is needed. We can just scan the MPD, identify if there are any of these types of parts, and the publish the requirement on the download page. We're already going to scan the file for header and syntax complience so this doesn't really add on that much.
2011-08-24, 14:26
Some thoughts:
Why must the full mpd filename be prepended to every submodel? That's very redundant and makes for very long names. I think it's enough to only add something to embedded parts.
In spirit of the part standards you shouldn't allow spaces in the 'new' part names, so maybe only add 'unof-' infront of them e.g.: unof-33956.dat
Why don't use !keywords for the theme, it's already done for parts e.g. 6267.dat
Why must the full mpd filename be prepended to every submodel? That's very redundant and makes for very long names. I think it's enough to only add something to embedded parts.
In spirit of the part standards you shouldn't allow spaces in the 'new' part names, so maybe only add 'unof-' infront of them e.g.: unof-33956.dat
Why don't use !keywords for the theme, it's already done for parts e.g. 6267.dat
2011-08-24, 14:29
Willy Tschager Wrote:
-------------------------------------------------------
> Personally I would go for this and prohibit the
> usage of aliases or physical colored parts.
I agree, I never understood the need for colored parts anyway.
-------------------------------------------------------
> Personally I would go for this and prohibit the
> usage of aliases or physical colored parts.
I agree, I never understood the need for colored parts anyway.
2011-08-24, 14:33
The point is to have each file inside the MPD have a unique name. This is for file tracking purposes and to prevent file overlap if the MPDs are unrolled in 1 directory. As far as part naming, I'm trying to make this spec as loose as possible while still preserving some structure. This will allow more submissions in a shorter amount of time and not discourage the non-technical form submitting files.
Pages: 1 2