This bonus tool was removed for Rhino 5 - that is to say it was not updated for it… I have several people here that go back to V4 to use this tool to extract dashed lines for things like milling… Is this functionality exposed somewhere in RhinoCommon? I didn’t find it…
Thanks,
–Mitch
@dale I can’t remember - was this your tool? Any chance for V5, V6,/64?
Mitch, I guess that plug-in should still work on 32 bit V5…
-Pascal
The problem is that the plug-in in question has about 25 tools/commands and ALL of them are already in V5 except that one… I’d be afraid of name conflicts to say the least…
–Mitch
It turns out it will not work anyway… things are handled differently enough in V5 that none of that will work as is. It will just need to be a wishlist item.
-Pascal
Yes please!.. this one is missed a lot from V4 Labs…
Hi Jarek,
In the end, I created a script as a workaround - primarily for a friend who needs this for machining (engraving linetypes into material). It works OK for the most part, but it isn’t perfect. One of the problems is that I don’t really have the algorithm of how Rhino deals with applying linetypes to curves and it is different if it is a line/polyline or a NURBS curve. My re-creation of it is the best I could do for the moment.
The other thing is how it deals with linetypes that contain dots. My friend wanted that they translate to point objects - which makes the display a bit funny - but I also started work on a version that would replace them with a tiny line segment - say 10x the file tolerance or user specified. However, I never finished that version. If that interests you, I might get back to it…
Anyway, script below FWIW…
–Mitch
ExplodeLinetypeV1.py (6.5 KB)
Hi Mitch, thanks for sharing the script; I have no luck so far - seems like the scale of the linetype is off or not implemented in the script. The scale of curves generated in the script is much bigger than the original ones.
Attached is the sample file if you get a chance to look at what the problem may be.
thanks again-
jareksample_dashed_curve.3dm (74.0 KB)
Hi Jarek,
OK, definitely something going on here I don’t understand… maybe related to feet and inches, I don’t know. Your curve is about 1346’ feet long, file units inches… So length about 16162 inches or so.
The linetype pattern is listed as 5, 5 (5 unit (inch) line, 5 unit (inch) space), and the scale is listed as 500, so that means each line+space segment should be about 5000 inches long. That would mean that there would be only 3 segments or so in the whole curve on opening the file, but I see lots more - about 80 or so - and the segments actually measure only about 200 inches long.
I don’t know where the problem is actually - all I know is that the script relies on picking up the linetype pattern definition and the scale from the file, and those do not match with what I’m seeing on the screen… Like there’s another scale factor somewhere that I’m not picking up.
???
–Mitch
OK, I see something… it looks to be a mm-inch thing, thus the scale is off by a factor of 25.4. If I look at the linetype dialog in doc properties, inches is checked and the pattern definition is .1969, .1969. If I change it to mm, I get 5, 5.
The problem is, despite the fact that the file is in inches, when I read the linetype pattern from the file via RhinoCommon, I get the values in mm. @stevebaer This appears to be a bug in RhinoCommon… Run the following on your file above:
import rhinoscriptsyntax as rs
import scriptcontext as sc
objID=rs.GetObject("Select curve",4,True)
objLT=rs.ObjectLinetype(objID)
lts=sc.doc.Linetypes
for lt in lts:
if lt.Name==objLT:
#get pattern data
pattern=[]
for i in range(lt.SegmentCount):
pattern.append(lt.GetSegment(i)[0])
print pattern
You will get 5,5 despite the fact that the file units are in inches.
As a workaround, I can check the current file units and scale between mm and whatever the file units are in. I’ll look at implementing that tomorrow… But this is not ideal, hopefully it can be fixed so it’s not necessary.
As everyone here works in mm, I never picked this up, thanks. It looks like files in cm and meters have the same problem… Worse, it looks like if you change the unit system on the file without scaling, the linetype does not follow suit and everything gets completely messed up. So it’s not only a RhinoCommon problem, it looks to be a Rhino problem. So now, at this point, I’m not sure what can be done to guarantee it working.
–Mitch
Linetype lengths are always defined in mm in RhinoCommon. I wouldn’t consider this a bug in the SDK, but probably something that we should do a better job of documenting.
OK, as long as that is a constant for all files and won’t change, I can adapt my script, thanks!
–Mitch
@Jarek OK, try this on “for size”… 
(seems to work with your example)
–Mitch
ExplodeLinetypeV11.py (6.9 KB)
Edit:
And here is a version that substitutes tiny line segments for dots (if any) in the pattern (which may make it easier to engrave if that’s the goal). User can set the line segment length, by default 10x the file absolute tolerance. Not tested extensively… 
ExplodeLinetypeV12.py (8.6 KB)
is there a way we can make the grouped lines return to their existing layer? as opposed them all being created onto the current layer??
Good question - probably - let me look into it… --Mitch
OK @jessegould have a go with this one…
Edit: small modification to transfer all original object attributes (not just layer, but also color, etc.) to new exploded curves.
ExplodeLinetypeV13.py (9.0 KB)
thankyou thankyou thankyou.
Thank You!! Works great!