+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Administrative (https://forums.ldraw.org/forum-4.html)
+--- Forum: Standards Board (https://forums.ldraw.org/forum-5.html)
+--- Thread: Proposed new LDRAW_ORG qualifier for Lsynth subparts (/thread-22248.html)
Proposed new LDRAW_ORG qualifier for Lsynth subparts - Chris Dee - 2017-08-07
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-NNAny concerns?
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Philippe Hurbain - 2017-08-07
OK for me!
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Travis Cobbs - 2017-08-07
(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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Chris Dee - 2017-08-08
(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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Willy Tschager - 2017-08-08
Fine with me.
w.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Roland Melkert - 2017-08-08
(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
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Chris Dee - 2017-08-08
(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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Steffen - 2017-08-13
[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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Roland Melkert - 2017-08-14
(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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Willy Tschager - 2017-08-16
(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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Philippe Hurbain - 2017-08-16
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)
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Willy Tschager - 2017-08-16
(2017-08-16, 10:43)Philippe Hurbain Wrote: 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.cgi?f=parts/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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Willy Tschager - 2017-08-21
(2017-08-16, 13:09)Willy Tschager Wrote:(2017-08-16, 10:43)Philippe Hurbain Wrote: 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.cgi?f=parts/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):
Quote: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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Roland Melkert - 2017-08-21
(2017-08-21, 10:45)Willy Tschager Wrote: 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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Magnus Forsberg - 2017-08-21
(2017-08-21, 10:45)Willy Tschager Wrote: 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?
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Willy Tschager - 2017-09-03
Please proceed to gate A and vote!
w.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Philippe Hurbain - 2017-09-03
(2017-09-03, 10:44)Willy Tschager Wrote: Please proceed to gate A and vote!I vote yes!
w.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Travis Cobbs - 2017-09-04
(2017-09-03, 10:44)Willy Tschager Wrote: Please proceed to gate A and vote!
w.
Yes.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Roland Melkert - 2017-09-04
(2017-09-03, 10:44)Willy Tschager Wrote: Please proceed to gate A and vote!
w.
I vote Yes
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Willy Tschager - 2017-09-10
This is the final boarding call for passengers Mr Dee booked on LDRAW_ORG qualifier for Lsynth. Please proceed to gate A immediately.
w.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Chris Dee - 2017-09-10
(2017-09-10, 10:40)Willy Tschager Wrote: 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!
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Chris Dee - 2017-12-05
(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?
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.
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Philippe Hurbain - 2017-12-05
Out of curiosity... is there a hidden meaning behind the choice of "k"?
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Magnus Forsberg - 2017-12-05
(2017-12-05, 18:40)Philippe Hurbain Wrote: Out of curiosity... is there a hidden meaning behind the choice of "k"?
Could be that it works very well in a germanic language...
RE: Proposed new LDRAW_ORG qualifier for Lsynth subparts - Chris Dee - 2017-12-06
(2017-12-05, 18:49)Magnus Forsberg Wrote:(2017-12-05, 18:40)Philippe Hurbain Wrote: 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.