Topic: Tutorial Ideas

[scout]

Yes they have!  Which is why I found it funny that three or four days prior to producing said tutorial Dana Probert was asking how to do XDREFS in C3D on the ADESK newsgroups.  So mostly I did it just for her .

Did you now? Usually when you do something special for someone you let them know.

I'll have to watch it. Too bad you didn't post the link to the C3D DG posting.  It might have driven some traffic to your site. (Or wherever you may have posted it. Do you have a website?)

http://discussion.autodesk.com/thread.jspa?messageID=5720119

BTW- there was no resolution to that issue.  The project was for soil borings and test pits on a DOT site.  No matter what, the surfaces seemed to keep flipping to the current override.  Does your AVI show how to avoid that problem? If so, I will owe you one.

[mjfarrell]

Scout,

The website is here:  http://www.primeservicesglobal.com/Tutorials.htm
.
The surfaces or points do not flip to any other state in my example.  Download and watch the AVI, if you want the dataset used you will need to send email request for same.  Thanks for the idea of posting to the C3D DG, perhaps we are already even.

Note: See Tongue in Cheek detail

[mjfarrell]

OK, this is a case of the Service Pack breaking something that wasn't in need of fixing.

So any of you that have the ear of the product development team, it's time to give them an earfull.  I'm a long way from home, and can not recall IF or which SP is installed on that machine.  Here at the clients office they have AutoCAD Civil 3D 2008 SP2 installed and the XDREF does not function properly.

The points continually assume the incorrect properties, irrespective of any combination of settings or process including LOCKING the point group.  This is just plain bad programming on Autodesks' part, and failure to properly test the SP's before offering them to the public to install.  This lies right on the edge of Criminal.


The good news is it still works at home, the bad news IF you installed the SP it won't work as shown in the AVI.  The short answer would be UNINSTALL C3D, and reinstall bare-naked version and your XDREFS will function as desired. :ugly:

[scout]

I'll see if I can't get some action and explaination.

[mjfarrell]

I eagerly await the response.

And should the client want to get'er done, they can, just with the pain of uninstalling to remove the flawed SP.

[scout]

if possible, it might help if you can record a very short avi on their machine (or another SP2 machine) that shows how the connection was made and the malfunction.  if an avi is not possible, a few screen captures illustrating things going wrong makes a big difference in getting the point across.

i have already contacted the QA person because I think this might help explain my issues as well.

[scout]

i have been contacted by QA and it is not a known issue.  If you do have a chance to record an avi and get a dataset together I'd be happy to put you in contact with the right person.

You can contact me though this forum or my email.

[mjfarrell]

I am ready; and have sent you my number.

[mjfarrell]

Scout, thanks for first spotting this issue with the XDREFS being whacked!
Second it looks like the documentation of the beast behaving 'in the wild' should prove helpfull in killing it.

[Dinosaur]

I was reviewing the pipe network feature settings tutorial and remembered another idea I had for a topic.  The values I enter in these dialogs seem to reflect themselves in the command settings, but if a change is made directly in a command setting it doesn't always reflect back into the feature settings.  It seems that whatever value that resides in the command setting trumps everything else and there are a lot more settings in there as well.  Could you try doing something on how to use the command settings in conjunction with the feature settings and object layer settings.  Perhaps also touching on whether or not to protect those settings and if so, when?

[mjfarrell]

I was reviewing the pipe network feature settings tutorial and remembered another idea I had for a topic.  The values I enter in these dialogs seem to reflect themselves in the command settings, but if a change is made directly in a command setting it doesn't always reflect back into the feature settings.  It seems that whatever value that resides in the command setting trumps everything else and there are a lot more settings in there as well.  Could you try doing something on how to use the command settings in conjunction with the feature settings and object layer settings.  Perhaps also touching on whether or not to protect those settings and if so, when?

First; go now and verify that you have set the Ambient Setting in your drawings' settings variable "ALLOW COMMAND CHANGES to SETTINGS" and turn it OFF or False because then you get the override behaviour you speak of.

For most user this should be the default, as then changing the standard settings at the command level is more deliberate.

[Dinosaur]

I always have ambient settings in my drawing set so to save changes to command settings. 

[mjfarrell]

I suggest that you do not want this turned on.

The idea being, you set your desired setting at the Feature level and everywhere else.
And then you turn that thing on, and VIOLA' now your standards are whatever was last
entered NOT what you spent your time setting them to be.

Left OFF the user must consciously decide, "I am about to change the standard for this, should I?"
for instance that they CHOOSE to do something otherwise. 

[Dinosaur]

I suggest that you do not want this turned on.

The idea being, you set your desired setting at the Feature level and everywhere else.
And then you turn that thing on, and VIOLA' now your standards are whatever was last
entered NOT what you spent your time setting them to be.

Left OFF the user must consciously decide, "I am about to change the standard for this, should I?"
for instance that they CHOOSE to do something otherwise. 

I understand that, but whatever it is we have in place for standards is in what seems to be in a perpetual state of flux.  I have been leaving it set to save changes to preserve any change that I like and restore from a copy of my template with the last best settings when the change has unexpected results.
OK, I will try turning it off while doing real work outside of the template, but I could swear I was told somewhere that setting to save was the best practice.

[mjfarrell]

"....was ^NOT the best....."

In some instances it could be argued that leaving it turned on allows the change to stick thus saving some time. I put forth that by making not save your changes it is likely to introduce errors when something other than the desired standard settings applied case by case. The best case for this is in your site grading criteria sets where setting these and locking them is a good idea, however one could always install a SPECIAL cases tool that would be unlocked so that in those spacial cases the grading could be handled at the point of creation.

In short; leave it on IF you are the master of your design domain and want to change inputs as you run with scissors go ahead.

If not, keep the brakes on going downhill.