LDraw.org Discussion Forums

Full Version: Proposed new LDRAW_ORG qualifier for Lsynth subparts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
We frequently discuss the anomaly of placing files representing subsections of flexible parts in the LDraw Parts folder to facilitate manual and LSynth construction of flexed renders.

The current header standards do not permit a '0 LDRAW_ORG Subpart' line in the header of a file in the parts folder.

I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like


Code:
0 !LDRAW_ORG Part Flexible_section UPDATE YYYY-NN

Any concerns?
OK for me!
(2017-08-07, 20:23)Chris Dee Wrote: [ -> ]We frequently discuss the anomaly of placing files representing subsections of flexible parts in the LDraw Parts folder to facilitate manual and LSynth construction of flexed renders.

The current header standards do not permit a '0 LDRAW_ORG Subpart' line in the header of a file in the parts folder.

I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like


Code:
0 !LDRAW_ORG Part Flexible_section UPDATE YYYY-NN

Any concerns?

I'd have to test, but LDView might mistake the sub-parts as parts. If the composite part using the sections isn't detected as being a part, LDView would add seam scaling to the sections, which would be bad. Simply having the files in the official parts directory might trigger the same thing, though. I can't remember.
(2017-08-07, 23:37)Travis Cobbs Wrote: [ -> ]
(2017-08-07, 20:23)Chris Dee Wrote: [ -> ]We frequently discuss the anomaly of placing files representing subsections of flexible parts in the LDraw Parts folder to facilitate manual and LSynth construction of flexed renders.

The current header standards do not permit a '0 LDRAW_ORG Subpart' line in the header of a file in the parts folder.

I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like


Code:
0 !LDRAW_ORG Part Flexible_section UPDATE YYYY-NN

Any concerns?

I'd have to test, but LDView might mistake the sub-parts as parts. If the composite part using the sections isn't detected as being a part, LDView would add seam scaling to the sections, which would be bad. Simply having the files in the official parts directory might trigger the same thing, though. I can't remember.

They are in the Parts directory right now, just not clearly identified.
Fine with me.

w.
(2017-08-07, 20:23)Chris Dee Wrote: [ -> ]I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like

Code:
0 !LDRAW_ORG Part Flexible_section UPDATE YYYY-NN

Any concerns?

I don't mind adding the hint just a little nitpick, if we do I think it should be  Flexible_Section  (cap S) to stay in sync with Physical_Colour
(2017-08-08, 18:49)Roland Melkert Wrote: [ -> ]
(2017-08-07, 20:23)Chris Dee Wrote: [ -> ]I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like

Code:
0 !LDRAW_ORG Part Flexible_section UPDATE YYYY-NN

Any concerns?

I don't mind adding the hint just a little nitpick, if we do I think it should be  Flexible_Section  (cap S) to stay in sync with Physical_Colour

I agree. It's nice to have someone paying attention to this detail. Thank you.
[quote pid='25848' dateline='1502137415']
> I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like
[/quote]

I think that that is not needed, because LSYNTH files either can be
- parts
or
- subparts
but nothing 3rd.

Their only "problem" is that they have to be "misplaced" into the PARTS folder currently,
as long as nobody extends LSYNTH with the tiny modification to also look in the PARTS\S folder.

Thus, I don't feel that a new header syntax is missing, because the existing header syntax already correctly allows to express what a file _is_.
What is not possible today is to put the file into its proper folder,
but that's not the fault of the file.
Introducing the new header element masks this problem away by attributing the file with something new,
but that for me only falsifies the otherwise already correct contents of the file.
What must be corrected is their location, not contents IMHO.
(2017-08-13, 22:14)Steffen Wrote: [ -> ]What must be corrected is their location, not contents IMHO.

This actually makes very much sense,

Steffen is right it should not be different then any normal official part existing out of repeating subparts (e..g the rubber bands, and flex axles). Except these subparts could be unused by the library it self.

The only other difference I can think of is the fact LSynth subparts often are used in overlap, which might cause them to be different then ones whom are used in 'real' parts. Not sure if that is enough to justify the new attribute though.
(2017-08-13, 22:14)Steffen Wrote: [ -> ]Their only "problem" is that they have to be "misplaced" into the PARTS folder currently,
as long as nobody extends LSYNTH with the tiny modification to also look in the PARTS\S folder.

Pinged Don, but have no idea if he is still reading his hotmail account. Does anybody have an alternative address?

w.
Pages: 1 2 3