+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: How do we handle obsolete official subparts? (/thread-6256.html)
How do we handle obsolete official subparts? - Nils Schmidt - 2012-09-18
..I did not find the answer to this simple question on the following pages:
File Types FAQ
File Format 1.0.2
Tracker FAQ
In addition to that question, I would like to know if it is allowed to change the orientation of official subparts.
Re: How do we handle obsolete official subparts? - Michael Heidemann - 2012-09-18
So far I have understand our procedure, we leave the parts where they are - parts\s - untouched. So any old model can load.
For backwards compatibility we avoid any change of orientation for parts. I assume that nobody uses a subpart in a model file, so if the calling part reflects the change of origin and stays the same for itself, I can not see at present any reason for not changing the origin of a subpart.
But i wonder why you want to change the orientation of a subpart. This does not make sense to me.
Re: How do we handle obsolete official subparts? - Philippe Hurbain - 2012-09-18
Michael Heidemann Wrote:I assume that nobody uses a subpart in a model fileI wouldn't even assume that. Maybe someone somewhere use them to create their custom parts! (OK, unlikely - but possible!)
Re: How do we handle obsolete official subparts? - Tim Gould - 2012-09-18
Although if someone is a sophisticated user who can use subparts to customise new parts, they can probably handle a shift of origin. Particularly if the old origin/angle is marked in a meta.
Tim
Re: How do we handle obsolete official subparts? - Steffen - 2012-09-18
A special role play subparts which are used for 3D-sweeping, e.g. by LSYNTH.
I think that our recent practice was to not change subpart's origin etc because we weren't sure that users
used them from custom files created on their own.
I think we should stick with this defensive strategy, although this might create some unused lurking files
in the \s folder when we need to do a thorough change. Such a change would then require to create a new subfile.
However, this strategy should not be a GO / NO GO strategy. Defensive reasoning should *allow* certain changes to a subfile:
Origin changes are not the only problematic ones.
Imagine a subfile which contains a surface, and we decide to remove that like "without Top Surface" etc. for patterning.
This also can create incompatibilities with users who directly use those subparts.
Forbidding us to do such changes would mean to produce quite a lot of clutter in the \S folder.
We would have to each time we modify a subfile make a copy and do the changes there.
The same goes for color changes or geometric adjustments.
If you sum this up, the trouble for us will be BIG when we would forbid subfile changes.
The trouble for some users using these subfiles will be SMALL when we change them.
People doing so will be experienced, and will know that this can happen.
For these reasons, my suggestion is: allow such changes.
Our "official" outside visible "interface" is the set of \parts and \p rimitives,
plus the few handful of subparts which are intended for 3D-sweeping (like LSYNTH).
This for me is a reasonable compromise between making life for parts authors easy
and at the same time keeping downwards compatibility to a certain degree.
Perfect downwards compatibility would only be achieved if we would NEVER touch a subfile again
after it has been released. This anyway cannot be achieved.
Re: How do we handle obsolete official subparts? - Philippe Hurbain - 2012-09-19
Steffen Wrote:Origin changes are not the only problematic ones.Very good point, Steffen. If we want to keep subparts intact then we can't do anything... so I withdraw what I said about origin/orientation.
Imagine a subfile which contains a surface, and we decide to remove that like "without Top Surface" etc. for patterning.
This also can create incompatibilities with users who directly use those subparts.