Proposed new LDRAW_ORG qualifier for Lsynth subparts

[Chris Dee]

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?

[Philippe Hurbain]

OK for me!

[Travis Cobbs]

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.

[Chris Dee]

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.

[Willy Tschager]

Fine with me.

w.

[Roland Melkert]

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

[Chris Dee]

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.

[Steffen]

[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.

[Roland Melkert]

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.

[Willy Tschager]

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.

[Philippe Hurbain]

The problem is not strictly a problem with Lsynth! People using cad system without flex part extension (mlcad, leocad) might want to "manually" build custom flex parts using segments. Tedious, but rather easy, done that many times in the past... So the segments MUST be in parts folder to be accessible by users! That's why I find Chris proposal to be a good one (none of these older cad system cares about real part type)

[Willy Tschager]

The problem is not strictly a problem with Lsynth! People using cad system without flex part extension (mlcad, leocad) might want to "manually" build custom flex parts using segments. Tedious, but rather easy, done that many times in the past... So the segments MUST be in parts folder to be accessible by users! That's why I find Chris proposal to be a good one (none of these older cad system cares about real part type)

While I can think of using http://www.ldraw.org/cgi-bin/ptdetail.cg...s/572d.dat I really can't for http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=680. I also think that they aren't either Parts or Subparts but something in between and support Chris proposal.

Nonetheless, LSynth should look into more folders than just Parts.

w.

[Willy Tschager]

The problem is not strictly a problem with Lsynth! People using cad system without flex part extension (mlcad, leocad) might want to "manually" build custom flex parts using segments. Tedious, but rather easy, done that many times in the past... So the segments MUST be in parts folder to be accessible by users! That's why I find Chris proposal to be a good one (none of these older cad system cares about real part type)

While I can think of using http://www.ldraw.org/cgi-bin/ptdetail.cg...s/572d.dat I really can't for http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=680. I also think that they aren't either Parts or Subparts but something in between and support Chris proposal.

Nonetheless, LSynth should look into more folders than just Parts.

w.

I've got mail from Don (hwho cannot post in the LSC forum):

Anyhow, I don't think lsynth opens any part files, not even the lsynth subparts.
It only reads lsynth.mpd and a model file that could be anywhere in the filesystem (I think).
So it's only the ldraw viewer/editor programs that might care about headers or PARTS folders.

--Don--

I therefore run a test with LSynth through MLCad (stupid me I didn't before). Anyhow I moved all the 0 ~Technic Tread 680.dat - 682.dat from the parts folder to the s folder. I then loaded the TECHNIC_TREAD example from my site http://www.holly-wood.it/lsynth/examples-en.html and run it through MLCad:

* The Tread was synthesized perfectly, but MLCad, even after generating a new Parts.lst file did not show it. LDCad didn't show it neither while LDView had non problem loading them. I therefore (and strong of Philo's arguments) would introduce a new qualifier, make them visible and add Flex part or something like this to the description.

w.

[Roland Melkert]

I therefore run a test with LSynth through MLCad (stupid me I didn't before). Anyhow I moved all the 0 ~Technic Tread 680.dat - 682.dat from the parts folder to the s folder. I then loaded the TECHNIC_TREAD example from my site http://www.holly-wood.it/lsynth/examples-en.html and run it through MLCad:

* The Tread was synthesized perfectly, but MLCad, even after generating a new Parts.lst file did not show it. LDCad didn't show it neither while LDView had non problem loading them. I therefore (and strong of Philo's arguments) would introduce a new qualifier, make them visible and add Flex part or something like this to the description.

With the parts in the s folder, the model should reference them as s\* as the s folder is not a direct search folder.

I think the only way to fix it so existing models keep working and search path rules stay in place, is by introducing the new qualifier so new software knows these are special parts which are actually more like subparts.

I admit it isn't strictly 'clean' but if you think about it these files can actually be used as parts and subparts depending on the user placing them or a generator adding them to a real part.

[Magnus Forsberg]

I therefore (and strong of Philo's arguments) would introduce a new qualifier, make them visible and add Flex part or something like this to the description.

Isn't it a problem that some of the wanted "sub"-parts are placed in the s-folder and some in the parts-folder?
I'm thinking of, among others, the subparts s/faxle1 - faxle5 in the Technic Flexaxles. They wouldn't be visible for a model author until they are moved to the parts-folder. Right?

[Willy Tschager]

Please proceed to gate A and vote!

w.

[Philippe Hurbain]

Please proceed to gate A and vote!

w.

I vote yes!

[Travis Cobbs]

Please proceed to gate A and vote!

w.

Yes.

[Roland Melkert]

Please proceed to gate A and vote!

w.

I vote Yes

[Willy Tschager]

This is the final boarding call for passengers Mr Dee booked on LDRAW_ORG qualifier for Lsynth. Please proceed to gate A immediately.

w.

[Chris Dee]

This is the final boarding call for passengers Mr Dee booked on LDRAW_ORG qualifier for Lsynth. Please proceed to gate A immediately.

w.

Of course, YES.  I proposed it!

[Chris Dee]

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?

This was agreed and has been added to the standards, but we didn't discuss file naming. It the past we have used (wasted) three-digit or uXXXX part numbers on the flexible section components. This is contrary to the current expectation that the LDraw part number matches the LEGO designID so that each part number represents a single moulding.

I have introduced a new naming convention such that flexible section components of parts shall be named with a kNN suffix - e.g. 30218k01.dat and 30218k02.dat as the component parts of 30218. I am working on an update to the Part numbers FAQ and will include this.

[Philippe Hurbain]

Out of curiosity... is there a hidden meaning behind the choice of "k"?

[Magnus Forsberg]

Out of curiosity... is there a hidden meaning behind the choice of "k"?

Could be that it works very well in a germanic language...

[Chris Dee]

Out of curiosity... is there a hidden meaning behind the choice of "k"?

Could be that it works very well in a germanic language...

Yes - you are correct - k for komponent.