I never noticed the extra files being added by etransmit, but a user pointed them out to me.
So I open etransmit, and sure enougfh, there is a category on the Files Tree that must be related to the extra files, but no way to see what files are listed under it so I can uncheck them.
see image attached.
I looked at the transmittal setup, its not the "include data links" option.
Seems pretty screwed up to me.
It wastes my time looking through the xrefs, then does not distinguish what is from xrefs and what from C3D?
And I thought the crashes from etransmit were bad, it is actually worse?
that sounds logical, but it not the behavior going on.
I have no drefs in the sheet I am etransmitting, though there is the chance some xrefs have a dref surface or two someone forgot to detach. We do not use drefs for display of linework in our sheets.
Either way, for C3D to automatically gather those, with no option to turn that off, is very narrow sighted of Autodesk.
Even if we did use drefs extensively, its narrow sighted.
THen to add a malfunction to the mix on top of it is downright typical, what was I expecting....
There actually is a setting to avoid DREFs in the eTransmit. Modify the Ttransmittal Setup and uncheck the "Include files from data links" option. Hope this helps.
A question to add to this, but how can you set a relative path for a Civil3D depency when eTransmitting?? I have a surface definition linked to and ESRI Adf file. When you eTransmit it comes up under the Civil3D dependencies, but remains path specific to the original location of the file.
When I send to a third party, the ADF file is included, but the path in the surface definition is to the location where I set it, and not to the location of the in the zipped package.
Before Autodesk addresses convenient handling of these kinds of paths, they need to deal with giving the user the ability to turn off all the automatic modifications going on.
At Hunsaker, I tell my users not to use Etransmit because it crashes so much.
We keep our files clean, but also deal with files from the outside that we batch convert but some still throw things off.
Etransmit should not "dig" into the drawings if we don't want it to.
Actually, we would not care if it worked, but I see long delays from reading in files, then lockups when trying to do the transmit, likely from acad trying to modify the outgoing files.
Its screwed up good. We wrote our own tool to gather xrefs and copy files, works 100.0000% of the time, always.
Its actually free too, part of the PurgeIDs tool I give out.
We batch convert if sending to ower versions, to kill the aec objects, but that is not often.
So correct handling of civil 3d reference paths is like asking to fix a whistle on a steam train, which is on fire....
Its a valid request, but not loud enough compared to the current noise.
yes, email at jmaeding hunsaker
put an @ between the words, and .com on the end.
which versions of acad do you need it for?
Access a broad range of knowledge to help get the most out of your products and services.
Start with some of our most frequented solutions or visit the Installation and Licensing Forum to get help installing your software.
Upgrading to a 2015 product? Make sure to check these out 1st!