Creating a new linetype?

How hard is it to create a new linetype?

I'm thinking one that would work as a revsion cloud, controlling the arc
size by changing the linetype scale.

Maybe this has already been done.

Maybe someone's already thought of this and discovered it's a bad idea.

Thanks,

Bill

 

It's already been done.

 

What ver autocad? Try typing revcloud.

 

Thanks, Rudy.

Soooo....where can I get it?

Bill

 

he does not want to use rev cloud.. "work as rev cloud".. not the
actual command..

he wants a line type that will "look" like a RC, but will remain the
same size no matter what scale the VP is at.. (very handy.. i've seen
it on a few surveys).

 

Hi, Walt.

2002.

I don't like revcloud. It's hard to control (start, stop, straight lines),
can't use ortho, polar, snaps or osnaps. IMO, it looks pretty amateur. IIRC,
I had the control I desire when I used Softdesk's AEC tools.

But it seems to me that a linetype would work although I've never created my
own custom linetype, so I don't know how difficult that is. I would rather
obtain it from someone else who has already done it.

Thanks,

Bill

 

First create a file called "tree3.shp" and enter this:
;;TREELINE
*136,84,TREE3
4,101,4,99,3,61,3,21,3,128,002,9,(127,0),(1,0),(0,0),001,9,(-4,12),(-3,6),(-12,1
5),(-5,4),(-6,3),(-5,3),(-6,3),(-6,2)
(-7,1),(-6,1),(-6,0),(-7,-1),(-6,-1),(-12,-4),(-6,-3),(-5,-3),(-5,-4),(-5,-5),(-
8,-10),(-3,-5),(-3,-6),(-2,-6),(0,-2)
(0,0),002,9,(0,0),001,4,128,4,21,4,61,3,99,3,101,0

Save it and in Acad say "Compile." Follow the directions to make the new shp
file.

Then edit Acad.lin and insert this:

*TREELN,Treeline
A,0,[TREE3,s=.033],-.26,[TREE3,,s=.0167],-.13

If it bothers you to call it treeline, rename it to cloud. I use it for both.

Easiest way to use it is SKETCH. Set it for pline.

rs

First create a file called "tree3.shp" and enter this:
;;TREELINE
*136,84,TREE3
4,101,4,99,3,61,3,21,3,128,002,9,(127,0),(1,0),(0,0),001,9,(-4,12),(-3,6),(-12,1
5),(-5,4),(-6,3),(-5,3),(-6,3),(-6,2)
(-7,1),(-6,1),(-6,0),(-7,-1),(-6,-1),(-12,-4),(-6,-3),(-5,-3),(-5,-4),(-5,-5),(-
8,-10),(-3,-5),(-3,-6),(-2,-6),(0,-2)
(0,0),002,9,(0,0),001,4,128,4,21,4,61,3,99,3,101,0

Save it and in Acad say "Compile." Follow the directions to make the new shp
file.

Then edit Acad.lin and insert this:

*TREELN,Treeline
A,0,[TREE3,s=.033],-.26,[TREE3,,s=.0167],-.13

If it bothers you to call it treeline, rename it to cloud. I use it for both.

Easiest way to use it is SKETCH. Set it for pline.

rs

 

<sigh>
.. . . .
A,0,[TREE3,s=.033],-.26,[TREE3,s=.0167],-.13
.. . . .

rs

 

Your choice - also, revcloud with cligraphy is available from 2000 or 2002.

 

Walt -

The caligraphy option doesn't solve the line control problem.

But thanks anyway.

Bill

 

O.K., I did this (twice).
I got no directions to make the new shp file. I just got the following
message:

Compilation successful. Output file C:\Program Files\AutoCAD
2002\Support\treeline.shx contains 127 bytes.

When I try to open acad.lin, I get the following error:
---------------------------
AutoCAD
---------------------------
Bad definition of TREELN at line 123 of file C:\Program Files\AutoCAD
2002\support\acad.lin
---------------------------
OK
---------------------------
This is what it looks like in my acad.lin:

*TREELN,Treeline
A,0,[TREE3,s=.033],-.26,[TREE3,s=.0167],-.13

Any ideas what I did wrong?

TIA,

Bill

 

But it compiled, eh? You probably had the good sense to remove the line wraps. I
forgot about that and tried it myself. It wouldn't compile until I put the lines
back together.

Here it is, straight out of my acad.lin -- I had to make it "tree4" to avoid
conflict.

*Tree4,Tree4
A,0,[tree4,C:\Land4\C\TREE4.shx,s=.033],-.26,[tree4,C:\Land4\C\TREE4.shx,s=.0167
],-.13

(again, watch for wordwrap)

My bad, I forgot to include the path. Works better now.

If you use sketch you need to set skpoly to 1. Also need to set Plinetype to 1
or 2.

Here's a little lisp function which will make it more transparent

(defun c:cld( / ) ;use treeln linetype to make a cloud
(setq ltold(getvar "celtype"))
(setq ptyold(getvar "plinetype"))
(setvar "celtype" "treeline")
(setvar "plinetype" 1)
(command "sketch" "")
;(command "pline" (while (/= (getvar "cmdactive") 0)
; (command pause)))
(command "pedit" "l" "close" "spline" "")
(setvar "celtype" ltold)
(setvar "plinetype" ptyold)
(princ))

I haven't decided whether I like Sketch or Pline so I included both. Just
comment out the alternate one.

With a little more polishing we should be able to come up with a duplicate of
the native command.

rs

 

Try defining a shape that's a single arc, and putting it into a linetype
similar to the way AutoCAD's Batting and Zigzag linetypes work.

Without analyzing it very deeply, it looks to me like TCEBob's TREE3 shape
is a multi-bulge sort of irregular thing that could look fine for a
treeline, but may not have the look you want for a revision cloud. (And I'm
puzzled by some of its elements, like apparent multiple scalings up and down
all together, but let that pass....)

But for a revision cloud, I think you want something as short as possible,
namely a single arc. Any shape definition that ends up back at zero in the
X direction will work fine in a complex linetype for a straight application,
but when you use it on an arc, or circle, or arc segment of a polyline, the
shape is put in tangent to the curve at the point of its insertion. So the
longer the shape is, and the tighter the curve, the farther the successive
shapes will be from meeting at their ends.

Try drawing an arc using the Batting or Zigzag linetypes, and make it a
pretty tight curve with a pretty big relative linetype scale, and you'll see
that the shapes don't touch at the ends. The mismatch can be more obvious
if you do a polyline made of straight line segments, with Linetype
Generation enabled, and look at the bends. They make it better (at least in
curved situations) in the linetype definition by offsetting the shape
"backward" by half the distance between shapes, so the tangent point is in
the middle of the shape location, and the mismatch is minimized, and equal
on both ends. (Muddy enough for you? Look at the effects on-screen, and
study the shape definition and linetype definition, to get the idea.) But
the longer the shape is, the greater will be the mismatch on curves and
bends, which is why you should keep the shape as short as possible.

To be sure you know how long it is, it's probably best to do the
bulge-specified arc (shape-definition code 12). You could add something to
ltypeshp.shp, like:

*136,4,CLOUDARC
12,2,0,70

(Change the 136 if you already have extra shapes defined in there, and the
70 if you don't like that amount of bulge.) That gives you an arc 2 "units"
long, just like the "length" of the Batting shape. (Re-compile ltypeshp.shp
into a new ltypeshp.shx.) Then make a "copy" linetype of Batting in
acad.lin, change the name and substitute in the cloudarc shape, and leave
out Batting's inverted second insertion, something like:

*REVISION,Revision Cloud Arcs \_/\_/\_/\_/ <not a very good visual
approximation, but what can you do?>
A,.0001,-.1,[CLOUDARC,ltypeshp.shx,x=-.1,s=.1],-.1

[NOT TESTED!]

Drawbacks:
As with Revcloud, you have to draw it in the correct direction, or the arcs
bulge inward instead of outward.
If the length isn't just right in relation to the linetype cycle, there will
be straight-line (or plain-curve) portions at the ends. It can't adjust to
close cleanly the way Revcloud does.
If you make a polyline cloud of straight segments, with linetype generation,
there will be mismatches at the corners. If you make the same shape with
individual lines, or a polyline without linetype generation, the ends will
meet but there will usually be straight-line pieces at all of the ends.
If you make a polyline cloud with curves, there will be mismatches along the
curves, though if they're gentle enough curves relative to the linetype
scale, you may not notice.
Unlike Revcloud, you can't snap to the visible bulges on this linetype. If
you put a typical triangle with a number in it to indicate the revision
number, and want to connect it with a line to the cloud, with Revcloud you
can snap to Nearest or Midpoint or Endpoint or Perpendicular or whatever on
any of the bulges, because they're polyline arc segments. But if you snap
to something like that on a cloud made with this linetype, it'll go to the
"base" path of the line/arc/polyline/circle, which won't actually be on the
visible cloud edge except at the endpoints of the arcs on straight segments
of the cloud boundary (but even where they do lie on the path like that, you
can't snap to them with Endpoint osnap).

Good luck!

Kent Cooper, AIA

 

Merely telling him about the availability of this neat feature which is not
in 2004 - nothing to do with want he wants.

 

I still get an error:
---------------------------
AutoCAD
---------------------------
Bad definition of REVISION at line 123 of file C:\Program Files\AutoCAD
2002\support\acad.lin
---------------------------
OK
---------------------------
This is part of my acad.lin:
A,.0001,-.2,[ZIG,ltypeshp.shx,x=-.2,s=.2],-.4,[ZIG,ltypeshp.shx,r=180,x=.2,s
=.2],-.2
*REVISION,Revision Cloud Arcs
A,.0001,-.1,[CLOUDARC,ltypeshp.shx,x=-.1,s=.1],-.1
(I included the ZIG above to show that paths are not the problem)
This is part of my revised ltypeshp.shp file:

*1,5,CLOUDARC
12,2,0,70,0

*130,6,TRACK1
014,002,01C,001,01C,0

Thanks for the help.

Bill

 

Nothing is obviously wrong to me. Some things to check:

The shape number after the asterisk has to be unique to the file, so if
there's another shape definition starting with *1, in the same file, change
the number of one of them.

As TCEBob mentioned, there needs to be a return or blank line at the end of
a shape definition file, but I'm not sure about a linetype definition file.
If the end of the Revision definition line is the end of the file, try going
there and hitting Enter to put a blank line at the end.

(Did ltypeshp.shp get recompiled into a new ltypeshp.shx file?)

Kent Cooper, AIA

.....

 

Kent -

The shape number is unique. This is my entire shape file:

*1,5,CLOUDARC
12,2,0,70,0

*130,6,TRACK1
014,002,01C,001,01C,0

*131,3,ZIG
012,01E,0

*132,6,BOX
014,020,02C,028,014,0

*133,4,CIRC1
10,1,-040,0

*134,6,BAT
025,10,2,-044,02B,0

I'm SURE there's a blank line at the end of the file. I'm using Notepad.
Isn't that O.K.?
Yes, I recompiled ltypeshp.shp. Just in case I forgot, I did it again.

What I'm thinking now is that I would be better of either knowing what I'm
doing in creating a new linetype instead of blindly taking direction (even
though I appreciate everyone's help), or use a routine that's already been
created.

BTW Kent, as an architect, what do you use to create revision clouds? I work
in the same "world" as a structural engineer.

Thanks,

Bill

 

Kent, et. al.;

I think I might have found the problem. I did have a cr and linefeed. It
appears that I had too many of 'em. I deleted all of them except for one,
recompiled and it works fine.

Further, so far, the line type approach to revision clouds seem to do what I
want it to do (snap, osnap, ortho, polar, etc. functions still work). I'm
not too worried about what it looks like in the corners.

Thanks for all the help.

Bill

 

Actually, I do use Revcloud. Before it existed, I built a sort of "system"
of unit-length blocks with different numbers of bulges, and lisp routines
that asked for endpoints, and based on the distance between them, chose one
of those blocks to put in, etc., etc. It made a respectable looking end
product, but was even more cumbersome to actually use than Revcloud is.

But, hey, maybe now that you've got this thing going, maybe I'll try it out
and see whether I like it better overall.

Kent Cooper, AIA

...
....

 

I'm glad you have a workable solution and I wish you well on your journey into
the future.

et al.