|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> I'm assuming the 80 char lines is what you're aiming for here, so based
> on the 64 char limit on descriptions I started the descriptions on the
> 16th character of the line. That gives room for a 15 character name
> and a single space before the description. Anything longer and you'll
> get the ragged look and a truncated description. But hey, if we keep
> most of the names to 11.3 and under it looks pretty nice:
>
> 6028.dat Animal Dragon Tail
> 6133.dat Animal Dragon Wing
> 6133longfilename.dat Animal Dragon Wing Long version
> 4493c00.dat Animal Horse (Complete)
>
> Here's what -8 does to the long filename. Is that ok?
>
> C:\LDraw>diff -b parts.lst parts.long
> 11c11
> < 6133LO~1.DAT Animal Dragon Wing Long version
> ---
> > 6133longfilename.dat Animal Dragon Wing Long version
>
> I put a beta executable here if anyone wants to shake the bugs out.
>
> http://ldglite.sf.net/mklist1_6b1.zip
Hey--that's exactly what I was looking for. Thanks!
Dave!
|
|
| |
In lugnet.cad.dat.parts.primitives, Chris Dee wrote:
> In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> > The current bushloc primitives are divided into 32 segments where as most of the
> > normal round type primitives are divided int 16 segments. Having noticed this I
> > uploaded new versions of bushloc2 and bushloc3. Then I looked at some of the
> > parts where the bushloc primitives get used and noticed some lines where the
> > maybe shouldn't be.
> > (see part 6577 at: http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/6577.dat)
> > These extra lines can easily be fixed by removing the inner edges on the bush
> > locks, but is this desirable or should the inner edges be left alone?
>
> I agree with what you have done to adjust bushloc2 and bushloc3 to fit
> 16-segment polygons:
> http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/bushloc2.dat
> http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/bushloc3.dat
>
> Fixing primtives is usually quite a challenge for the parts update process
> because all the affected parts need to be re-issued at the same time as the
> corrected primitive. However, in this case the dependency set is so small I
> think we should do it:
>
> bushloc2 is used only in:
> 4265a.dat - not on Parts Tracker
> 6542.dat - http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=6542
> 6577.dat - http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=6577
>
> bushloc3.dat is used only in:
> 4273a.dat - http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/4273a.dat
> 4273b.dat - http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/4273b.dat
>
> If you can re-work 4265a, and we can expedite the review of these parts then I
> can make sure these all get released together.
>
> Chris Dee (LDraw Parts Library Admin)
There's still the question of the interior edges though. Should they be removed
or left as if? Also some of these could benefit from use of subparts, a common
subpart for both 4273a and 4273b then another subpart to be used by 6577 and
4265a. Would use of a subparts be acceptable in this case?
|
|
| |
The current bushloc primitives are divided into 32 segments where as most of the
normal round type primitives are divided int 16 segments. Having noticed this I
uploaded new versions of bushloc2 and bushloc3. Then I looked at some of the
parts where the bushloc primitives get used and noticed some lines where the
maybe shouldn't be.
(see part 6577 at: http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/6577.dat)
These extra lines can easily be fixed by removing the inner edges on the bush
locks, but is this desirable or should the inner edges be left alone?
|
|
| |
In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> >
> > A cylinder with one closed end (4-4cylc.dat) was issued in the latest parts
> > update (2009-02). See http://www.ldraw.org/library/primref/#curv3d .
> > If there is a need for a 1-4cylc.dat, feel free to submit it to the Parts
> > Tracker.
> >
> > However, I'm struggling to see the utility of a cylinder with both ends open.
> > Can someone provide an example of where it might be useful.
> >
> > Chris Dee
Here is a list I compiled of many parts that could make use of a cylinder that's
open at both ends. There may be more.
6029A
3957
104
2569
30322
30209
3062B
33286
43888
4740
3960s01
3961s01
6942
75535
6177s01
30148
4360
4341
70501
529
6260
3878
|
|
| |
>
> A cylinder with one closed end (4-4cylc.dat) was issued in the latest parts
> update (2009-02). See http://www.ldraw.org/library/primref/#curv3d .
> If there is a need for a 1-4cylc.dat, feel free to submit it to the Parts
> Tracker.
>
> However, I'm struggling to see the utility of a cylinder with both ends open.
> Can someone provide an example of where it might be useful.
>
> Chris Dee
This type of primitive would mostly be used in places where a cylinder appears
between two other objects. One example would be the subpart at:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/s/636s1.dat
which currently uses 4-4cylc.dat where a 4-4cylo.dat (cylinder with edges open
at both ends) would be better.
|
|
| |
In lugnet.cad.dat.parts.primitives, Chris Dee wrote:
> However, I'm struggling to see the utility of a cylinder with both ends open.
> Can someone provide an example of where it might be useful.
>
> Chris Dee
Guess I replied way too soon. I may revise my earlier reply after giving it some
more thought. A 1/4 cylinder with both ends closed would of course be better for
rounded cornerns.
A cylinder with both ends open could be useful when making pipe-like shapes in
the likeness of stud2 and stud4, and holes. Don't know yet how commonly needed
they would be.
The question is: How common should a combined primitive have to be before it is
motivated to issue a .dat file for it? Guess it also depends on how many lines
can be saved and how hard it is to calculate and write by hand...
/T
|
|
| |
> A cylinder with one closed end (4-4cylc.dat) was issued in the latest parts
> update (2009-02). See http://www.ldraw.org/library/primref/#curv3d .
> If there is a need for a 1-4cylc.dat, feel free to submit it to the Parts
> Tracker.
4-4 and 2-4 cylc are released, 1-4 and 3-4cylc are already on PT.
> However, I'm struggling to see the utility of a cylinder with both ends open.
> Can someone provide an example of where it might be useful.
I think the usefulness is quite low indeed.
Philo
|
|
| |
In lugnet.cad.dat.parts.primitives, Tore Eriksson wrote:
> In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
> > In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> > > Is there any demand for this type of cylinder primitive that's open at both
> > > ends?
> >
> > Not being a part author, I can't comment on the utility, but to me the naming is
> > confusing. The base cylinder primitives are already open at both ends; they
> > just don't have edges there. So to me, cyle would make more since in the
> > filename, and "Cylinder with edges" in the description.
> >
> > --Travis
>
> Naming is not an important issue to me. Either name would be fine for me. The
> one important thing for me is that it doesn't mess up with renderers and
> utilities that make primitive substitutions. But I don't see that there should
> be any risk for that.
>
> But I sure have missed this combination, and also a "stud 1x1 w/o logo", ie a
> cylinder with one closed end, preferably the one at the y=1 end. I think 4/4 and
> 1/4 versions would be the ones of most use. 4/4 for many purposes, also holes,
> and 1/4 for rounded corners.
>
>
> So I suggest these four new primitives:
> 1/4 cylinder open with egdes
> 1/4 cylinder open with egdes and one disc
> 4/4 cylinder open with egdes
> 4/4 cylinder open with egdes and one disc
>
> When it comes to naming and descriptions, I have no opinion.
>
> /Tore
A cylinder with one closed end (4-4cylc.dat) was issued in the latest parts
update (2009-02). See http://www.ldraw.org/library/primref/#curv3d .
If there is a need for a 1-4cylc.dat, feel free to submit it to the Parts
Tracker.
However, I'm struggling to see the utility of a cylinder with both ends open.
Can someone provide an example of where it might be useful.
Chris Dee
|
|
| |
In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
> In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> > Is there any demand for this type of cylinder primitive that's open at both
> > ends?
>
> Not being a part author, I can't comment on the utility, but to me the naming is
> confusing. The base cylinder primitives are already open at both ends; they
> just don't have edges there. So to me, cyle would make more since in the
> filename, and "Cylinder with edges" in the description.
>
> --Travis
Naming is not an important issue to me. Either name would be fine for me. The
one important thing for me is that it doesn't mess up with renderers and
utilities that make primitive substitutions. But I don't see that there should
be any risk for that.
But I sure have missed this combination, and also a "stud 1x1 w/o logo", ie a
cylinder with one closed end, preferably the one at the y=1 end. I think 4/4 and
1/4 versions would be the ones of most use. 4/4 for many purposes, also holes,
and 1/4 for rounded corners.
So I suggest these four new primitives:
1/4 cylinder open with egdes
1/4 cylinder open with egdes and one disc
4/4 cylinder open with egdes
4/4 cylinder open with egdes and one disc
When it comes to naming and descriptions, I have no opinion.
/Tore
|
|
| |
In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> Is there any demand for this type of cylinder primitive that's open at both
> ends?
Not being a part author, I can't comment on the utility, but to me the naming is
confusing. The base cylinder primitives are already open at both ends; they
just don't have edges there. So to me, cyle would make more since in the
filename, and "Cylinder with edges" in the description.
--Travis
|
|
| |
Is there any demand for this type of cylinder primitive that's open at both
ends?
0 Cylinder open 1.0
0 Name: 4-4cylo.dat
0 Author: Mark Kennedy [mkennedy]
0 !LDRAW_ORG Unofficial_Primitive
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW
1 16 0 0 0 1 0 0 0 1 0 0 0 1 4-4edge.dat
1 16 0 1 0 1 0 0 0 1 0 0 0 1 4-4edge.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 4-4cyli.dat
0
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> Sorry to follow-up my own post, but I did a quick test on MLCAD.
>
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > Of course, if further MLCAD tests shows that it works with a fixed-format 25
> > char filename column, then there's less reason to go with the ragged format.
>
> I had a DUH! moment after posting the previous message. If MLCAD can use a
> ragged format file, of course it can use a fixed-25 format file. DOH.
>
> > So it would be nice to be able to produce a PARTS.LST with full descriptions if
> > rigid conformance to 80-byte records is not needed.
>
> I prepared a PARTS.LST file with data lines longer and shorter than 80
> bytes, and MLCAD seemed perfectly happy to use the data as presented.
> In particular, it could handle longer descriptions without truncating
> them (I didn't test to see if it had some longer limit).
In the mklist beta I posted there's an undocumented -r switch to turn
off the ragged edges and make room for 25 char filenames. There's also
an undocumented -t to twiddle with the 78 vs 80 character line formats.
But there's nothing yet for allowing descriptions longer than 64 chars.
We can add lots of options, but we also need to decide on the default
output format. And I suspect that should probably target whatever works
best for MLCAD users. Any newer programs currently in development can
create their own mklist type functions.
The -8 setting should produce 8.3 filenames and 80 character lines
(including the <CR><LF>) compatible with any older software out there.
Don
|
|
| |
Sorry to follow-up my own post, but I did a quick test on MLCAD.
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> Of course, if further MLCAD tests shows that it works with a fixed-format 25
> char filename column, then there's less reason to go with the ragged format.
I had a DUH! moment after posting the previous message. If MLCAD can use a
ragged format file, of course it can use a fixed-25 format file. DOH.
> So it would be nice to be able to produce a PARTS.LST with full descriptions if
> rigid conformance to 80-byte records is not needed.
I prepared a PARTS.LST file with data lines longer and shorter than 80 bytes,
and MLCAD seemed perfectly happy to use the data as presented. In particular,
it could handle longer descriptions without truncating them (I didn't test to
see if it had some longer limit).
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > I'd keep the current line-format for all parts conforming to the 8.3
> > format, but for longer names, print the entire filename, a space, and
> > the description. Like this:
> >
> > 3001.dat Brick 2 x 4
> > 3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
> > 3002.dat Brick 2 x 3
> >
> > A backwards-compatibility switch is good -- maybe with option to
> > truncate (or not) the description to fit 80 bytes per line?
I'm assuming the 80 char lines is what you're aiming for here, so based
on the 64 char limit on descriptions I started the descriptions on the
16th character of the line. That gives room for a 15 character name
and a single space before the description. Anything longer and you'll
get the ragged look and a truncated description. But hey, if we keep
most of the names to 11.3 and under it looks pretty nice:
6028.dat Animal Dragon Tail
6133.dat Animal Dragon Wing
6133longfilename.dat Animal Dragon Wing Long version
4493c00.dat Animal Horse (Complete)
Here's what -8 does to the long filename. Is that ok?
C:\LDraw>diff -b parts.lst parts.long
11c11
< 6133LO~1.DAT Animal Dragon Wing Long version
---
> 6133longfilename.dat Animal Dragon Wing Long version
I put a beta executable here if anyone wants to shake the bugs out.
http://ldglite.sf.net/mklist1_6b1.zip
Don
|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > 3001.dat Brick 2 x 4
> > 3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
> > 3002.dat Brick 2 x 3
> >
> > A backwards-compatibility switch is good -- maybe with option to
> > truncate (or not) the description to fit 80 bytes per line?
>
> Ok, I'd like to know what you're thinking here. The specs say 25 chars
> in the filenames, and I don't really like a ragged left edge on the
> descriptions, both visually and because it complicates the sorting code.
> So tell me why someone might want that, especially as more long
> filenames get released. It's gonna look awful.
My thinking is the 'ragged' format has the least impact - if there are no long
part nambers, then the output PARTS.LST would exactly match the classic format,
without the user having to know anything about long/short part nambers.
Of course, if further MLCAD tests shows that it works with a fixed-format 25
char filename column, then there's less reason to go with the ragged format.
> Right now, mklist always truncates the description to 64 chars, which
> fits on an 80 char line with the 8.3 filenames. I take it you'd like to
> (optionally?) make it instead truncate the filename+space(s)+description
> to 80 chars when using long filenames. Is there some program that this
> will help, or is this so it still fits in an 80 char terminal window?
I was thinking that some old programs depend on the rigid 80 byte record format,
but most programs are line-delimited, and don't care about the exact line
length. Over time, we've seen an increased need for longer, more detailed part
descriptions. In some cases, the 64 char description limit is already an issue
for part naming. For example, a number of the 6100 patterned baseplates break
the 'with ... Pattern' naming convention.
So it would be nice to be able to produce a PARTS.LST with full descriptions if
rigid conformance to 80-byte records is not needed.
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
>
> > I could update the mklist sources to work handle filenames with 25 chars
>
> That would be good, I think.
>
> > I was going to add a quietmode commandline option this weekend anyhow.
>
> Can you have two levels? Level One that still shows the warnings, but
> doesn't stop, and Level Two suppresses all warnings.
Yeah, I was actually planning a -f to force it to finish and -q for quiet.
> > Should I allow 25 chars as the default, and perhaps include an optional
> > command line arg to force/truncate it to 12 chars for backwards
> > compatibility with old programs?
For now I've added a -8 to make it use the 8.3 format. As per Travis'
suggestion it converts to the canonical short form under Windows. The
function uppercases the filenames, which should work ok for DOS/Windows,
but looks kinda ugly.
> I'd keep the current line-format for all parts conforming to the 8.3
> format, but for longer names, print the entire filename, a space, and
> the description. Like this:
>
> 3001.dat Brick 2 x 4
> 3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
> 3002.dat Brick 2 x 3
>
> A backwards-compatibility switch is good -- maybe with option to
> truncate (or not) the description to fit 80 bytes per line?
Ok, I'd like to know what you're thinking here. The specs say 25 chars
in the filenames, and I don't really like a ragged left edge on the
descriptions, both visually and because it complicates the sorting code.
So tell me why someone might want that, especially as more long
filenames get released. It's gonna look awful.
Right now, mklist always truncates the description to 64 chars, which
fits on an 80 char line with the 8.3 filenames. I take it you'd like to
(optionally?) make it instead truncate the filename+space(s)+description
to 80 chars when using long filenames. Is there some program that this
will help, or is this so it still fits in an 80 char terminal window?
Don
|
|
| |
In lugnet.cad.dat.parts.primitives, Michael Heidemann wrote:
> Sounds easy, but I think nobody can read that short filenames that would appear
> in the MLCad list!?
For MLCAD it doesn't matter. Steve said that MLCAD worked fine with long
filenames inside parts.lst. The only reason to put the short filename in is for
other programs that might have problems with the long filename. And as long as
mklist is run on the computer that is going to use the parts.lst file,
PathGetShortFilename will give the correct short filename for the given long
filename. The parts.lst file is then specific to that particular computer, but
that doesn't seem to be a problem if someone is running mklist themselves
anyway.
--Travis
|
|
| |
In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > A backwards-compatibility switch is good -- maybe with option to truncate (or
> > not) the description to fit 80 bytes per line?
>
> If it's running in Windows, I think a backwards-compatible switch should use the
> Win32 API to get the short filename (with the ~1 at the end, usually, determined
> using PathGetShortPath) and use that in place of the long filename.
>
> --Travis
Sounds easy, but I think nobody can read that short filenames that would appear
in the MLCad list!?
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> A backwards-compatibility switch is good -- maybe with option to truncate (or
> not) the description to fit 80 bytes per line?
If it's running in Windows, I think a backwards-compatible switch should use the
Win32 API to get the short filename (with the ~1 at the end, usually, determined
using PathGetShortPath) and use that in place of the long filename.
--Travis
|
|
|
