|
|
Unofficial File parts/x993.dat
Next File |
Prev File |
Download |
Review |
Edit |
CA Header Edit |
Events
File Header:
0 ~Electric Cable 3LDU Twin
0 Name: x993.dat
0 Author: Michael Heidemann [mikeheide]
0 !LDRAW_ORG Unofficial_Subpart
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CW
0 !HISTORY 2004-12-21 [mikeheide] initial version
0 !HISTORY 2004-12-22 [mikeheide] removed intersection quads
0 !HISTORY 2011-12-16 [Steffen] changed origin
0 !HISTORY 2013-03-30 [mikeheide] used cyli primitives like suggested
Status:
 Needs admin review. (CCCX)
Size: 740 bytes
Reviewers' certifications:
MagFors=certify
Steffen=certify
mikeheide=certify
Required (unofficial) subfiles:
(none)
Related (unofficial) files:
File reviews and updates:
At Tue Dec 21 22:54:04 2004, the file was initially submitted.
Submitted by: mikeheide
======================================================================
At Wed Dec 22 12:28:04 2004, the following review was posted:
Reviewer: Steffen
Certification: novote
Comments:
should the intersection of the two cylinders be removed?
======================================================================
At Wed Dec 22 19:42:02 2004, a new version of the file was submitted.
Submitted by: mikeheide
Existing certification-votes were deleted.
======================================================================
At Wed Dec 22 20:02:02 2004, a new version of the file was submitted.
Submitted by: mikeheide
Comments:
changed title
======================================================================
At Mon Jan 5 16:24:14 2009, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
strange filename, sorry
======================================================================
At Mon Jan 5 17:06:19 2009, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
part name needs some cleanup, too
======================================================================
At Sat Jan 31 18:25:59 2009 part 'parts/xwire.dat' was renamed to 'parts/x993.dat'.
======================================================================
At Sat Jan 31 20:34:01 2009, the following review was posted:
Reviewer: Steffen
Certification: novote
Comments:
thanks for renaming; whitespace still missing in part name
======================================================================
At Fri May 1 10:22:08 2009, the following review was posted:
Reviewer: Steffen
Certification: certify
Comments:
Admin, please add a space in part name on release
======================================================================
At Tue Jan 5 21:12:47 2010, the following review was posted:
Reviewer: Steffen
Certification: novote
Comments:
I'm no longer sure that this is correct being a part.
Shouldn't it be a subpart?
======================================================================
At Wed Jan 6 09:18:29 2010, the following review was posted:
Reviewer: mikeheide
Certification: novote
Comments:
Please remember discussion about such parts on other parts. They are needed to build another flexible part, so the has to be visible in some way to the user. Thats why we have pushed some of the to parts.
I strongly recommend this to be a part.
======================================================================
At Thu Feb 3 23:20:03 2011, the following review was posted:
Reviewer: Steffen
Certification: novote
Comments:
2 questions here:
a)
What's the difference between the two files currently on the PT x993.dat vs. ls10.dat?
I suggest to delete both and replace them by one or more
cable *primitives*.
b)
I strongly disagree here regarding the "subpart" vs. "part" issue.
Just to make the part visible in e.g. the MLCad GUI is not worth
making it a part. Making it a part will mislead tools which compute
e.g. gaps between parts. They normally do so between parts, not between subparts. If we want to see this file in some tool's GUI,
that tool needs to be adjusted to e.g. display all parts that have
0 !KEYWORD LSynth
or similar. There are lots of possible solutions. In my eyes,
making this a part as a workaround is the worst of them.
======================================================================
At Sat Jul 2 17:15:09 2011, a new version of the file was submitted.
Submitted by: Steffen
Comments:
while correcting the header
0 ~Electric Twin Cable Segment diam.3LDU
0 Name: x993.dat
0 Author: Michael Heidemann [mikeheide]
0 Unofficial LCAD Part
to what you now see on the PT, I saw a possible compromise here:
we state type "Subpart" in the header, but leave this file visible
in the PARTS folder.
Existing certification-votes were deleted.
======================================================================
At Tue Jul 12 16:05:11 2011, the following review was posted:
Reviewer: mikeheide
Certification: certify
Comments:
Your thoughts are ok, but I do not know the way (for example) LDView determines to show gaps or not. So it is IMHO only a guess that this will work.
======================================================================
At Tue Jul 12 16:25:06 2011, the following review was posted:
Reviewer: Steffen
Certification: novote
Comments:
yes, it depends on the algorithm, but it should not hurt.
Instead, it is an opportunity to get things right.
I would like to CERT myself but don't feel allowed.
Anybody else?
======================================================================
At Tue Jul 12 16:35:04 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
yikes, just noticed that we still need to resolve the clash between
this and ls10.dat
plus the more generic question: how should LSynth parts be named
in our library?
I like publishing them together with the Parts,
but I think we should have some systematics there
======================================================================
At Tue Jul 12 16:40:03 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
- I do not like that lsynth files have a special filename "ls*".
I would prefer them to just have normal filenames like all other parts/subparts. LSynth can easily be configured to use them.
It's just a matter of parts lookup.
- Question to solve: how can these parts be made easily accessible
to the user? I suggest creating a new category. The name which
jumps to my mind of course is
!CATEGORY LSynth
, but that's tool specific. On the other hand, this could be taken
as abbreviation of "LDRAW Synthesized Part", so it would be okay :-)
======================================================================
At Tue Jul 12 18:10:03 2011, the following review was posted:
Reviewer: mikeheide
Certification: novote
Comments:
If you will have a look at the history lines you will see that this file is older.
William has explicit written that his file ls10.dat is only a placeholder because the ls10.dat has been used on some parts that have been on the PT in 2006 (and still are).
At present I have not checked the interchangability of both parts.
I made this file according to the cable I have on hands from TLC old days.
======================================================================
At Tue Jul 12 22:35:13 2011, the following review was posted:
Reviewer: Steffen
Certification: certify
Comments:
yes, as this part is okay, why not let it out.
Maybe we can refacture the parts currently using ls10.dat
to use this one.
after some more thinking about lsynth, I came to the following ideas:
currently, lsynth delivers some parts and some primitives.
the reason for that simply is that these were not official,
and the users needed them. once all these needed parts and primitives are official, this will no longer be necessary. lsynth then can
rely on the existing parts in the library. that's something
I would try to achieve.
there are 3 kinds of parts for lsynth, which are relevant in our
thoughts here:
1. the normal parts involved, e.g. minifig chain parts etc.
2. the primitives for synthesized parts like hoses, cables etc.
3. the constraint placeholder(s) needed for lsynth.
For all 3, I would like to see it that we include these parts
in the official library. the constraint placeholders are not program specific - any program similar to lsynth can use them to create
bent parts or e.g. chain assemblies.
so what we see here is something more generic:
it is a way to express synthesized parts in a scene in general.
for that, you need 1., 2. and 3.
so I see personally no problems, including all of these in a release.
the parts (1.) are anyway in it. once they are official, the lsynth
configurations can be updated to use them. no problem there.
the lsynth primitives in my eyes are not different than other primitives IMHO. for example, we have a primitive for a stud, and for the 12V train connector, and for the Duplo connector - why should we not have a primitive which is the basic element to generate a bent hose? or a cable? simply putting these lsynth primitives in our
primitives folder is something I would like to suggest here.
The user does not have to access them via GUI, as programs automatically pick the proper primitives when generating a part
(lsynth does, and other programs can as well). so these primitives
are well located in the P folder.
Just (3.) requires some more thought: where to put those?
They are similar to the light.dat file. A special placeholder part.
And for that, after thinking some more - I see no reason not to have them in our library. just as a normal part. why not? what does everybody else think? I currently do not like that lsynth brings some "special" parts which are not in our official library and therefore have to be kept matching manually.
======================================================================
At Thu Jul 21 21:00:06 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
damn, I just noticed that the origin of this file
does not match the other primitives which LSYNTH uses.
they have their origin at the top.
this has it at the center.
Is that okay?
Does LSYNTH need some special configuration to deal with that?
Can it deal with any origin?
I am very sorry to discover this this late.
I just played with LSYNTH a little. Mike?
======================================================================
At Thu Jul 21 21:10:03 2011, the following review was posted:
Reviewer: mikeheide
Certification: novote
Comments:
This is not a LSYNTH part. As I do not have much experience with LSynth I can not be of any good help here.
======================================================================
At Thu Jul 21 21:30:08 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
I just played a little more with LSYNTH and this file
to generate bent cables.
This file can directly be used by LSYNTH if its origin is moved
to the top, i.e., if it gets moved down in Y direction by 0.5.
This change will have 3 advantages in my eyes:
(a) part is directly usable by LSYNTH
(b) origin placement follows our usual policy
(c) scaling this part will just displace 1 end of this part,
while the other (the one at the origin) stays where it is.
This makes placing this part correctly a LOT easier.
So I greatly favor the relocation. Unfortunately this requires
updating all the current cable assembly parts on the PT,
however, I would like to volunteer for doing that.
Opinions?
======================================================================
At Thu Jul 21 23:05:03 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
just having written the above,
I really think this file should become a primitive,
in analogy to rail12v.dat.
It is the primitive from which you can generate cables.
Straight, or flexible (like e.g. generated by LSYNTH).
======================================================================
At Fri Jul 22 18:40:02 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
forgot to mention another advantage:
(d) doing that will give this file ("2 merged cylinders")
the same origin as the 4-4cyli primitive
======================================================================
At Sun Jul 31 00:15:07 2011, the following review was posted:
Reviewer: Steffen
Certification: hold
Comments:
holding this until a consensus about how to include
parts syntesizing (e.g. LSYNTH) in our library has been found,
see ongoing discussion at
http://forums.ldraw.org/read.php?21,199,199
======================================================================
At Fri Dec 16 03:15:04 2011, a new version of the file was submitted.
Submitted by: Steffen
Comments:
In some forum discussions the decision whether to include LSYNTH primitives in our library seems to still take a while.
However, it still makes sense here to adjust the origin as suggested
(relocate from subpart center to subpart top) for these reasons:
1. the origin placement and subpart height will then be identical to 4-4cyli.dat
2. the origin placement will allow LSYNTH to directly use this file, no necessity to provide an own one.
3. origin-at-top is our usual policy of origin placement
So by now adjusting this file and its parents,
I think we have a chance of getting the electric plugs and cables
out with the next release.
Existing certification-votes were deleted.
======================================================================
At Fri Dec 16 21:15:04 2011, the following review was posted:
Reviewer: MagFors
Certification: hold
Comments:
ERROR Filename for subparts has to start with 's\'. HOLD
x993.dat "~Electric Twin Cable Segment, 3LDU Diameter"
x994.dat "~Electric Twin Cable End Segment diam.3LDU"
Please adjust the names to a better likeness.
======================================================================
At Tue Dec 20 22:25:05 2011, a new version of the file was submitted.
Submitted by: Steffen
Comments:
Retitled as requested at
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/x993.dat
, see also
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/x994.dat
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/u9136.dat
for matching parts.
The discussion whether files like this should go into
- PARTS
- PARTS\S
- P
has been led over years now without fruitful result.
Here are the various opinions:
(1) PARTS:
Some people would like to see such files there,
because they this way can be seen in tools element selection GUI,
e.g. MLCad. Would the file sit in PARTS\S or P this would not be the case.
(2) PARTS\S:
Some people argument that this in fact is logically a subfile.
(3) P:
Thinking even more generic, this actually is a primitive.
My personal opinion is (3), because this would be the cleanest
structure in our library. We should IMHO not choose (1)
just because some existing tools cannot show parts from P.
Existing certification-votes were deleted.
======================================================================
At Tue May 1 02:05:03 2012, a new version of the file was submitted.
Submitted by: Steffen
Comments:
retitled
======================================================================
At Tue May 1 02:15:03 2012, a new version of the file was submitted.
Submitted by: Steffen
Comments:
retitled again
======================================================================
At Tue May 1 11:35:02 2012, a new version of the file was submitted.
Submitted by: Steffen
Comments:
restored ~ prefix
======================================================================
At Fri Mar 15 17:50:09 2013, the following review was posted:
Reviewer: mikeheide
Certification: certify
No comments were posted with this review.
======================================================================
At Mon Mar 18 21:50:05 2013, the following review was posted:
Reviewer: MMR1988
Certification: novote
Comments:
Just a question beside the Parts/Subparts discussion:
Is there a reason that the part isn't using cyli-prims?
======================================================================
At Sat Mar 30 08:15:07 2013, a new version of the file was submitted.
Submitted by: mikeheide
Comments:
used cyli primitives.
Existing certification-votes were deleted.
======================================================================
At Sat Mar 30 19:55:01 2013, the following review was posted:
Reviewer: Steffen
Certification: certify
No comments were posted with this review.
======================================================================
At Sat Mar 30 23:05:02 2013, the following review was posted:
Reviewer: mikeheide
Certification: certify
No comments were posted with this review.
======================================================================
At Fri Apr 5 21:35:01 2013, the following review was posted:
Reviewer: MagFors
Certification: certify
No comments were posted with this review.
|
3 subfiles aren't certified. (SSSX)