 | | | | | | |
| |
|
It is common practice to prefix parts that compose assembled parts with a ~.
This prevent using them needlessly (they are not listed with regular parts),
encouraging the use of assembled shortcuts.
But this practice is not ratified by any official LDraw document. As a LDraw
Standards Committee member, I'd like to precise this usage. This is a request
for comments...
Things are clear for fixed assemblies, such as
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/53792.dat. Each compositing
element should have a prefixing ~, and user should normally use the shortcut.
~ should not be used for assembled part with moving elements, since the user
might have to assemble his own configuration. For example, hinge plates. Things
get even more complex for parts such as linear actuator
(http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/61927.dat), composed of
moving elements themselves formed of parts elements. Ideally, the leaf elements
(base, body, piston and piston head should get a ~ flag. A shortcut should be
made with base and body assembly, and piston/piston head would form a second
shortcut. These "subshortcuts" would have no ~ flag. Of course, origin and
orientation of these "subshortcuts" should be chosen so that assembled together
with the same orientation/origin they create a meaningful complete part.
Another question for those ~ flagged parts is category. Is a part named eg.
~Electric to be in the Electric category, or would it need a separate Category
statement? My personal feeling is that the ~ is just a flag and no separate
category statement is needed.
Thoughts?
Philo
| | | | | | | | | | | | | | | |
In lugnet.cad, Philippe Hurbain wrote:
> It is common practice to prefix parts that compose assembled parts with a ~.
> This prevent using them needlessly (they are not listed with regular parts),
> encouraging the use of assembled shortcuts.
I'd like to chime in on this but from another perspective: non-consistency when
using the tilde. The synthesized hose parts 755 and 756 have the tilde, but the
hose end parts 750 and 752 do not. Apply this logic to the minifig chain and
the link part 209 should have the tilde, but the end part 208 should not.
It would be key for a user-friendly usage when working with LSynth that "208.dat
- Minifig Chain Link End (Open File for Usage Guide)" gets "unhidden" in the
parts library.
w.
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > It is common practice to prefix parts that compose assembled parts
> > with a ~. This prevent using them needlessly (they are not listed
> > with regular parts), encouraging the use of assembled shortcuts.
>
> I'd like to chime in on this but from another perspective:
> non-consistency when using the tilde. The synthesized hose parts 755
> and 756 have the tilde, but the hose end parts 750 and 752 do not.
> Apply this logic to the minifig chain and the link part 209 should
> have the tilde, but the end part 208 should not.
>
> It would be key for a user-friendly usage when working with LSynth
> that "208.dat - Minifig Chain Link End (Open File for Usage Guide)"
> gets "unhidden" in the parts library.
I'd also like to chime in here to agree with Willy. To make a rubber
hose or a minifig chain with LSynth, you must first position the 2 end
parts manually. So you need to be able to find them in your parts
list. The synth process will place the internal segments, so you
don't really need to see those in your parts list. (If you're crazy
enough to place all the segments manually, then you're probably also
clever enough to find the internal parts without selecting them from a
parts list).
Does it make sense to create another prefix (like say *) for these
parts that you may need to place manually, but aren't actually whole
parts. That way the mklist program wouldn't necessarily hide them,
but a CAD program could be set up to optionally hide or list them?
We could use the same sort of thing for the moving parts of a piston
assembly.
Don
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > It is common practice to prefix parts that compose assembled parts with a ~.
> > This prevent using them needlessly (they are not listed with regular parts),
> > encouraging the use of assembled shortcuts.
>
> I'd like to chime in on this but from another perspective: non-consistency when
> using the tilde. The synthesized hose parts 755 and 756 have the tilde, but the
> hose end parts 750 and 752 do not. Apply this logic to the minifig chain and
> the link part 209 should have the tilde, but the end part 208 should not.
>
> It would be key for a user-friendly usage when working with LSynth that "208.dat
> - Minifig Chain Link End (Open File for Usage Guide)" gets "unhidden" in the
> parts library.
>
> w.
Hi folks,
since there is no opposition to this request I'm gonna unhide the 208 currently
at the PT:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=208
and since we are here would you confirm that the lenght of the chain has changed
over the years form 17.25 Studs to currently 16 Studs and that there are now two
versions of chain links which have to be authored?
w.
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Willy Tschager wrote:
> > In lugnet.cad, Philippe Hurbain wrote:
> > > It is common practice to prefix parts that compose assembled parts
> > > with a ~. This prevent using them needlessly (they are not listed
> > > with regular parts), encouraging the use of assembled shortcuts.
> >
> > I'd like to chime in on this but from another perspective:
> > non-consistency when using the tilde. The synthesized hose parts
> > 755 and 756 have the tilde, but the hose end parts 750 and 752 do
> > not. Apply this logic to the minifig chain and the link part 209
> > should have the tilde, but the end part 208 should not.
> >
> > It would be key for a user-friendly usage when working with LSynth
> > that "208.dat - Minifig Chain Link End (Open File for Usage Guide)"
> > gets "unhidden" in the parts library.
>
> since there is no opposition to this request I'm gonna unhide the
> 208 currently at the PT:
>
> http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=208
>
> and since we are here would you confirm that the lenght of the chain
> has changed over the years form 17.25 Studs to currently 16 Studs
> and that there are now two versions of chain links which have to be
> authored?
I can confirm two new sets (8958 and 6193) with the shorter chains.
And now that we've opened this can of worms, what about unhiding the
end studs (572a.dat) used in the pirate rigging and spiderman rope
parts (76384, 75924, 572C02, and 572C01)?
Don
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Philippe Hurbain wrote:
> It is common practice to prefix parts that compose assembled parts with a ~.
> This prevent using them needlessly (they are not listed with regular parts),
> encouraging the use of assembled shortcuts.
>
> But this practice is not ratified by any official LDraw document. As a LDraw
> Standards Committee member, I'd like to precise this usage. This is a request
> for comments...
There is one document that introduced this.
http://www.ldraw.org/library/tracker/ref/filetypesfaq/
I found we have different problems to solve:
1) Usage of the tilde '~' for files in the \s folder.
2) Usage of the tilde '~' for files in the \parts folder
3) Is the tilde '~' part of the description or only a flag.
I think as follow:
1) As nearly all files in the \s folder do have a leading '~' we should force
that for files in the s\ folder.
2a) I don't feel that we should make things that complicated.
If we have a shortcut for the complete part (as we have today). It is no problem
to figure out which parts to bring into a new file to get what we want.
The other way would blow up the library.
Just if you are working with MLCad it is not a problem to generate what you
need.
2b) To work with LSynth is really make sense to have the ends visible to find
that. Although also here a global shortcut will have all the user needs. And
again it is easy to identify what you need with MLCad.
But we should be consistent in using or not using the '~' for such parts.
3) As the '~' is used as a flag we should also handle it as that, so if there is
a partfile in the \parts folder that carry the '~' in front of the
partdescription the partdescription is assumed to be without the '~' and so the
first word has to be in the category list or a category has to be mentioned (See
requirement: http://www.ldraw.org/Article398.html).
This has also to be decided for the "_" flag for colored parts!
cu
mikeheide
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Michael Heidemann wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > It is common practice to prefix parts that compose assembled parts with a ~.
> > This prevent using them needlessly (they are not listed with regular parts),
> > encouraging the use of assembled shortcuts.
> >
> > But this practice is not ratified by any official LDraw document. As a LDraw
> > Standards Committee member, I'd like to precise this usage. This is a request
> > for comments...
>
>
> There is one document that introduced this.
> http://www.ldraw.org/library/tracker/ref/filetypesfaq/
>
> I found we have different problems to solve:
> 1) Usage of the tilde '~' for files in the \s folder.
> 2) Usage of the tilde '~' for files in the \parts folder
> 3) Is the tilde '~' part of the description or only a flag.
>
> I think as follow:
> 1) As nearly all files in the \s folder do have a leading '~' we should force
> that for files in the s\ folder.
>
> 2a) I don't feel that we should make things that complicated.
> If we have a shortcut for the complete part (as we have today). It is no problem
> to figure out which parts to bring into a new file to get what we want.
> The other way would blow up the library.
> Just if you are working with MLCad it is not a problem to generate what you
> need.
>
> 2b) To work with LSynth is really make sense to have the ends visible to find
> that. Although also here a global shortcut will have all the user needs. And
> again it is easy to identify what you need with MLCad.
> But we should be consistent in using or not using the '~' for such parts.
>
> 3) As the '~' is used as a flag we should also handle it as that, so if there is
> a partfile in the \parts folder that carry the '~' in front of the
> partdescription the partdescription is assumed to be without the '~' and so the
> first word has to be in the category list or a category has to be mentioned (See
> requirement: http://www.ldraw.org/Article398.html).
> This has also to be decided for the "_" flag for colored parts!
>
> cu
> mikeheide
As I am in the beta testing for the new DATHeader I need to have decisions for
the above questions.
At present many of the above is mixed on the PT.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Michael Heidemann wrote:
> In lugnet.cad, Michael Heidemann wrote:
> > In lugnet.cad, Philippe Hurbain wrote:
> > > It is common practice to prefix parts that compose assembled parts with a ~.
> > > This prevent using them needlessly (they are not listed with regular parts),
> > > encouraging the use of assembled shortcuts.
> > >
> > > But this practice is not ratified by any official LDraw document. As a LDraw
> > > Standards Committee member, I'd like to precise this usage. This is a request
> > > for comments...
> >
> >
> > There is one document that introduced this.
> > http://www.ldraw.org/library/tracker/ref/filetypesfaq/
> >
> > I found we have different problems to solve:
> > 1) Usage of the tilde '~' for files in the \s folder.
> > 2) Usage of the tilde '~' for files in the \parts folder
> > 3) Is the tilde '~' part of the description or only a flag.
> >
> > I think as follow:
> > 1) As nearly all files in the \s folder do have a leading '~' we should force
> > that for files in the s\ folder.
> >
> > 2a) I don't feel that we should make things that complicated.
> > If we have a shortcut for the complete part (as we have today). It is no problem
> > to figure out which parts to bring into a new file to get what we want.
> > The other way would blow up the library.
> > Just if you are working with MLCad it is not a problem to generate what you
> > need.
> >
> > 2b) To work with LSynth is really make sense to have the ends visible to find
> > that. Although also here a global shortcut will have all the user needs. And
> > again it is easy to identify what you need with MLCad.
> > But we should be consistent in using or not using the '~' for such parts.
> >
> > 3) As the '~' is used as a flag we should also handle it as that, so if there is
> > a partfile in the \parts folder that carry the '~' in front of the
> > partdescription the partdescription is assumed to be without the '~' and so the
> > first word has to be in the category list or a category has to be mentioned (See
> > requirement: http://www.ldraw.org/Article398.html).
> > This has also to be decided for the "_" flag for colored parts!
> >
> > cu
> > mikeheide
>
> As I am in the beta testing for the new DATHeader I need to have decisions for
> the above questions.
> At present many of the above is mixed on the PT.
>
> cu
> mikeheide
1) the leading ~ should be enforced for files in parts/s.
2a) a leading ~ is optional for files in parts, but should be present for
physical components that are always delivered in combination with another.
2b) we need a better way to deal with this long-standing problem (maybe a
different prefix that LSynth understands, or maybe another category on the
!LDRAW_ORG line). In truth these should be subparts, but historically have been
placed in parts, and to support LSynth the "error" has been propogated.
3) the ~ is a label, as is the _, so is not part of the first word of the
description. So, "_Roadsign ..." does not need a !CATEGORY line.
Chris
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Chris Dee wrote:
> In lugnet.cad, Michael Heidemann wrote:
> > In lugnet.cad, Michael Heidemann wrote:
> > > In lugnet.cad, Philippe Hurbain wrote:
> > > > It is common practice to prefix parts that compose assembled parts with a ~.
> > > > This prevent using them needlessly (they are not listed with regular parts),
> > > > encouraging the use of assembled shortcuts.
> > > >
> > > > But this practice is not ratified by any official LDraw document. As a LDraw
> > > > Standards Committee member, I'd like to precise this usage. This is a request
> > > > for comments...
> > >
> > >
> > > There is one document that introduced this.
> > > http://www.ldraw.org/library/tracker/ref/filetypesfaq/
> > >
> > > I found we have different problems to solve:
> > > 1) Usage of the tilde '~' for files in the \s folder.
> > > 2) Usage of the tilde '~' for files in the \parts folder
> > > 3) Is the tilde '~' part of the description or only a flag.
> > >
> > > I think as follow:
> > > 1) As nearly all files in the \s folder do have a leading '~' we should force
> > > that for files in the s\ folder.
> > >
> > > 2a) I don't feel that we should make things that complicated.
> > > If we have a shortcut for the complete part (as we have today). It is no problem
> > > to figure out which parts to bring into a new file to get what we want.
> > > The other way would blow up the library.
> > > Just if you are working with MLCad it is not a problem to generate what you
> > > need.
> > >
> > > 2b) To work with LSynth is really make sense to have the ends visible to find
> > > that. Although also here a global shortcut will have all the user needs. And
> > > again it is easy to identify what you need with MLCad.
> > > But we should be consistent in using or not using the '~' for such parts.
> > >
> > > 3) As the '~' is used as a flag we should also handle it as that, so if there is
> > > a partfile in the \parts folder that carry the '~' in front of the
> > > partdescription the partdescription is assumed to be without the '~' and so the
> > > first word has to be in the category list or a category has to be mentioned (See
> > > requirement: http://www.ldraw.org/Article398.html).
> > > This has also to be decided for the "_" flag for colored parts!
> > >
> > > cu
> > > mikeheide
> >
> > As I am in the beta testing for the new DATHeader I need to have decisions for
> > the above questions.
> > At present many of the above is mixed on the PT.
> >
> > cu
> > mikeheide
>
> 1) the leading ~ should be enforced for files in parts/s.
> 2a) a leading ~ is optional for files in parts, but should be present for
> physical components that are always delivered in combination with another.
> 2b) we need a better way to deal with this long-standing problem (maybe a
> different prefix that LSynth understands, or maybe another category on the
> !LDRAW_ORG line). In truth these should be subparts, but historically have been
> placed in parts, and to support LSynth the "error" has been propogated.
> 3) the ~ is a label, as is the _, so is not part of the first word of the
> description. So, "_Roadsign ..." does not need a !CATEGORY line.
>
> Chris
Thanks for make that clear now.
I have just also link this post in the wiki
(http://www.ldraw.org/wiki/index.php/LDraw_Specifications_Discussions) so we can
find it much quicker in the future.
I have also put there a lot of other stuff that I feel we should keep for future
use.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Chris Dee wrote:
> In lugnet.cad, Michael Heidemann wrote:
> > > 2b) To work with LSynth is really make sense to have the ends visible to find
> > > that.
Working with the new version 3.1 I've announced today you'll notice that we
included unhidden version of the Minifig Chain and String parts along with the
LSynth constraints to work around this problem so changing the standard is no
longer key for us but it would help.
w.
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Michael Heidemann wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > It is common practice to prefix parts that compose assembled parts with a ~.
> > This prevent using them needlessly (they are not listed with regular parts),
> > encouraging the use of assembled shortcuts.
> >
> > But this practice is not ratified by any official LDraw document. As a LDraw
> > Standards Committee member, I'd like to precise this usage. This is a request
> > for comments...
>
>
> There is one document that introduced this.
> http://www.ldraw.org/library/tracker/ref/filetypesfaq/
>
> I found we have different problems to solve:
> 1) Usage of the tilde '~' for files in the \s folder.
> 2) Usage of the tilde '~' for files in the \parts folder
> 3) Is the tilde '~' part of the description or only a flag.
>
> I think as follow:
> 1) As nearly all files in the \s folder do have a leading '~' we should force
> that for files in the s\ folder.
>
> 2a) I don't feel that we should make things that complicated.
> If we have a shortcut for the complete part (as we have today). It is no problem
> to figure out which parts to bring into a new file to get what we want.
> The other way would blow up the library.
> Just if you are working with MLCad it is not a problem to generate what you
> need.
>
> 2b) To work with LSynth is really make sense to have the ends visible to find
> that. Although also here a global shortcut will have all the user needs. And
> again it is easy to identify what you need with MLCad.
> But we should be consistent in using or not using the '~' for such parts.
>
> 3) As the '~' is used as a flag we should also handle it as that, so if there is
> a partfile in the \parts folder that carry the '~' in front of the
> partdescription the partdescription is assumed to be without the '~' and so the
> first word has to be in the category list or a category has to be mentioned (See
> requirement: http://www.ldraw.org/Article398.html).
> This has also to be decided for the "_" flag for colored parts!
>
> cu
> mikeheide
Hi,
I read the above article and is OK, but many parts do not follow these
requirements:
for example part 71427C01.DAT distributed as official is named as assembly but
contains the whole part definition inside with no references to any subparts but
parts\P parts.
In my personal opinion, from a programmer point of view, it could be a good
practice to correctly code as assembly at least those parts that allow
reciprocal movement in between them.
For example a switch has a lever that moves while the base is static; a motor
has an axle that rotate while the rest of the model is static.
Other assembly should be multicolored parts (with the exclusion of patterned
parts), since sometime these color can change.
One more question: what does the suffixes "Dxx" and "Txx" stand for?
regards...
Sergio
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Sergio Reano wrote:
> In lugnet.cad, Michael Heidemann wrote:
> > In lugnet.cad, Philippe Hurbain wrote:
> > > It is common practice to prefix parts that compose assembled parts with a ~.
> > > This prevent using them needlessly (they are not listed with regular parts),
> > > encouraging the use of assembled shortcuts.
> > >
> > > But this practice is not ratified by any official LDraw document. As a LDraw
> > > Standards Committee member, I'd like to precise this usage. This is a request
> > > for comments...
> >
> >
> > There is one document that introduced this.
> > http://www.ldraw.org/library/tracker/ref/filetypesfaq/
> >
> > I found we have different problems to solve:
> > 1) Usage of the tilde '~' for files in the \s folder.
> > 2) Usage of the tilde '~' for files in the \parts folder
> > 3) Is the tilde '~' part of the description or only a flag.
> >
> > I think as follow:
> > 1) As nearly all files in the \s folder do have a leading '~' we should force
> > that for files in the s\ folder.
> >
> > 2a) I don't feel that we should make things that complicated.
> > If we have a shortcut for the complete part (as we have today). It is no problem
> > to figure out which parts to bring into a new file to get what we want.
> > The other way would blow up the library.
> > Just if you are working with MLCad it is not a problem to generate what you
> > need.
> >
> > 2b) To work with LSynth is really make sense to have the ends visible to find
> > that. Although also here a global shortcut will have all the user needs. And
> > again it is easy to identify what you need with MLCad.
> > But we should be consistent in using or not using the '~' for such parts.
> >
> > 3) As the '~' is used as a flag we should also handle it as that, so if there is
> > a partfile in the \parts folder that carry the '~' in front of the
> > partdescription the partdescription is assumed to be without the '~' and so the
> > first word has to be in the category list or a category has to be mentioned (See
> > requirement: http://www.ldraw.org/Article398.html).
> > This has also to be decided for the "_" flag for colored parts!
> >
> > cu
> > mikeheide
>
> Hi,
> I read the above article and is OK, but many parts do not follow these
> requirements:
> for example part 71427C01.DAT distributed as official is named as assembly but
> contains the whole part definition inside with no references to any subparts but
> parts\P parts.
>
> In my personal opinion, from a programmer point of view, it could be a good
> practice to correctly code as assembly at least those parts that allow
> reciprocal movement in between them.
> For example a switch has a lever that moves while the base is static; a motor
> has an axle that rotate while the rest of the model is static.
>
> Other assembly should be multicolored parts (with the exclusion of patterned
> parts), since sometime these color can change.
>
> One more question: what does the suffixes "Dxx" and "Txx" stand for?
>
> regards...
>
> Sergio
The part you mentioned is certified a long time ago and rules changes over the
time. So you will find surely old part in the library that are not according our
current rules.
Also the ...Cxx only advices that the real part is assembled by some parts. They
are not neccessarily also modeled for LDraw.org with subparts but it would be
best practice today.
Suffix "Dxx" is for parts with an sticker already attached. I can not find now
the discussion for that but I am sure that this is correct.
Do you have an example for "Txx"?
cu
mikeheide
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Sergio Reano wrote:
> In lugnet.cad, Michael Heidemann wrote:
> > In lugnet.cad, Philippe Hurbain wrote:
> > > It is common practice to prefix parts that compose assembled parts with a ~.
> > > This prevent using them needlessly (they are not listed with regular parts),
> > > encouraging the use of assembled shortcuts.
> > >
> > > But this practice is not ratified by any official LDraw document. As a LDraw
> > > Standards Committee member, I'd like to precise this usage. This is a request
> > > for comments...
> >
> >
> > There is one document that introduced this.
> > http://www.ldraw.org/library/tracker/ref/filetypesfaq/
> >
> > I found we have different problems to solve:
> > 1) Usage of the tilde '~' for files in the \s folder.
> > 2) Usage of the tilde '~' for files in the \parts folder
> > 3) Is the tilde '~' part of the description or only a flag.
> >
> > I think as follow:
> > 1) As nearly all files in the \s folder do have a leading '~' we should force
> > that for files in the s\ folder.
> >
> > 2a) I don't feel that we should make things that complicated.
> > If we have a shortcut for the complete part (as we have today). It is no problem
> > to figure out which parts to bring into a new file to get what we want.
> > The other way would blow up the library.
> > Just if you are working with MLCad it is not a problem to generate what you
> > need.
> >
> > 2b) To work with LSynth is really make sense to have the ends visible to find
> > that. Although also here a global shortcut will have all the user needs. And
> > again it is easy to identify what you need with MLCad.
> > But we should be consistent in using or not using the '~' for such parts.
> >
> > 3) As the '~' is used as a flag we should also handle it as that, so if there is
> > a partfile in the \parts folder that carry the '~' in front of the
> > partdescription the partdescription is assumed to be without the '~' and so the
> > first word has to be in the category list or a category has to be mentioned (See
> > requirement: http://www.ldraw.org/Article398.html).
> > This has also to be decided for the "_" flag for colored parts!
> >
> > cu
> > mikeheide
>
> Hi,
> I read the above article and is OK, but many parts do not follow these
> requirements:
> for example part 71427C01.DAT distributed as official is named as assembly but
> contains the whole part definition inside with no references to any subparts but
> parts\P parts.
>
> In my personal opinion, from a programmer point of view, it could be a good
> practice to correctly code as assembly at least those parts that allow
> reciprocal movement in between them.
> For example a switch has a lever that moves while the base is static; a motor
> has an axle that rotate while the rest of the model is static.
>
> Other assembly should be multicolored parts (with the exclusion of patterned
> parts), since sometime these color can change.
>
> One more question: what does the suffixes "Dxx" and "Txx" stand for?
>
> regards...
>
> Sergio
Please understand that the LDraw Parts Library is over 12 years old and
standards evolve over time. Things that were done in 1999, when 71427c01.dat was
created, wouldn't necessarily be done the same way now.
*dNN.dat files are parts with stickers applied
*tNN.dat files are non-standard, and the only representative in the official is
in fact a ~Moved to (i.e re-direct) file .
Chris
| | | | | | | | | | | | | | | | | |
| |
|
> > requirement: http://www.ldraw.org/Article398.html).
> > Hi,
> > I read the above article and is OK, but many parts do not follow these
> > requirements:
> > for example part 71427C01.DAT distributed as official is named as assembly but
> > contains the whole part definition inside with no references to any subparts but
> > parts\P parts.
> >
> > In my personal opinion, from a programmer point of view, it could be a good
> > practice to correctly code as assembly at least those parts that allow
> > reciprocal movement in between them.
> > For example a switch has a lever that moves while the base is static; a motor
> > has an axle that rotate while the rest of the model is static.
> >
> > Other assembly should be multicolored parts (with the exclusion of patterned
> > parts), since sometime these color can change.
> >
> > One more question: what does the suffixes "Dxx" and "Txx" stand for?
> >
> > regards...
> >
> > Sergio
>
> Please understand that the LDraw Parts Library is over 12 years old and
> standards evolve over time. Things that were done in 1999, when 71427c01.dat was
> created, wouldn't necessarily be done the same way now.
>
> *dNN.dat files are parts with stickers applied
> *tNN.dat files are non-standard, and the only representative in the official is
> in fact a ~Moved to (i.e re-direct) file .
>
> Chris
I can understand the problem of aged parts, but, again from a programmer
approach, I have to manage both "old" and "new" parts, so it will be very
helpful if all parts can follow the same coding and naming standard.
Please, consider the following example to understand what kind of problem I get:
when I open a part, if it not an assembly I load all its graphics definition in
the same memory storage since the whole parts moves. If it is an assembly,
instead, I will load each "subpart" in different storage since one or more of
them can move while other doesn't.
If something is wrong then it could happen that some mechanism wont move or the
whole part move (like in the motor example) and so the whole model will move
since the motor chassis is "connected" to the rest of the model.
If someone can correct the old parts, I can build and send the list of parts
needing fixes.
Sergio
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Sergio Reano wrote:
> > > requirement: http://www.ldraw.org/Article398.html).
>
> > > Hi,
> > > I read the above article and is OK, but many parts do not follow these
> > > requirements:
> > > for example part 71427C01.DAT distributed as official is named as assembly but
> > > contains the whole part definition inside with no references to any subparts but
> > > parts\P parts.
> > >
> > > In my personal opinion, from a programmer point of view, it could be a good
> > > practice to correctly code as assembly at least those parts that allow
> > > reciprocal movement in between them.
> > > For example a switch has a lever that moves while the base is static; a motor
> > > has an axle that rotate while the rest of the model is static.
> > >
> > > Other assembly should be multicolored parts (with the exclusion of patterned
> > > parts), since sometime these color can change.
> > >
> > > One more question: what does the suffixes "Dxx" and "Txx" stand for?
> > >
> > > regards...
> > >
> > > Sergio
> >
> > Please understand that the LDraw Parts Library is over 12 years old and
> > standards evolve over time. Things that were done in 1999, when 71427c01.dat was
> > created, wouldn't necessarily be done the same way now.
> >
> > *dNN.dat files are parts with stickers applied
> > *tNN.dat files are non-standard, and the only representative in the official is
> > in fact a ~Moved to (i.e re-direct) file .
> >
> > Chris
>
> I can understand the problem of aged parts, but, again from a programmer
> approach, I have to manage both "old" and "new" parts, so it will be very
> helpful if all parts can follow the same coding and naming standard.
>
> Please, consider the following example to understand what kind of problem I get:
> when I open a part, if it not an assembly I load all its graphics definition in
> the same memory storage since the whole parts moves. If it is an assembly,
> instead, I will load each "subpart" in different storage since one or more of
> them can move while other doesn't.
>
> If something is wrong then it could happen that some mechanism wont move or the
> whole part move (like in the motor example) and so the whole model will move
> since the motor chassis is "connected" to the rest of the model.
>
> If someone can correct the old parts, I can build and send the list of parts
> needing fixes.
>
> Sergio
Maybe you are trying to interpret too much from the naming convention. A
composite part (*cNN.dat) isn't necessarily comprised of parts that can move
relative to each other, It might just be made of two or more separately moulded
elements that are connected in a fixed configuration. Even if the separate
elements are moveable, there is no assurance that the rotation origon can be
deduced. So I think you have some big challenges here.
One solution might be to extend the metadata in the parts files, or include
separate "connection" information in the library in some other form. This has
been talked about before as an "LDraw Connections Database" project.
Please be careful not to misuse the term "subpart". That has a semantic meaning
in LDraw that does not mean "constituent part". The term is used to refer to a
separate file of re-used lines and surfaces, that is rarely, if ever, a closed
solid.
If you have analysed the library to identify which composite parts are not built
of parts, then please post it so that authors can work on bringing the library
up to the current conventions. Or maybe you could even take in some of that work
yourself?
Chris
| | | | | | |
