Ridge_Runner

I was hoping the OP would do that.

They don't position very well due to the skew angle and the pitch of the roof. Many times I have tried modifying a rafter for a different roof element and it will just drop down to a 0 pitch; it just seems to loose it's bearing in 3D space (or maybe I loose my bearing in 3D space).

Do a forum search using these terms. These have been discussed in the past; several comments about how to do it. Short answer - can't be done automatic. Has to be done as a workaround.

To each his own, but I always measure as-builts to the inside of the jamb/frame; it's the opening size I am most concerned about. The trim can be whatever (I do measure it to make sure I record any differences). The cabinet guy will take his own measurements and adjust accordingly. I take tons of pictures so I get the as-built visuals as close as possible as the real world, but don't worry with such things as reveals.

Did anyone else record? Sure hope so. Would like to see how others work; I always pick up some good tidbits along the way.

I gave some thought to doing this in my own workflow. May do it yet if we get another slowdown. With the price/availability struggle here (read sky high price and lack of availability of even studs at times) I may just get that time! Hope not, but the next few months will tell.

I think C1...short for Corona1! That way, if anything goes wrong, it can be blamed on someone or something else.

Same here. I do several a year.

Are you using "Layout Line Scaling" when you send your views to layout? I always have this checked.

Maybe I don't understand what you are wanting to do, but this would be a disaster for condocs. I don't use a large number of line weights, but I use a variety from 1 to 75 (1,10,14,18,25,35,50,75 pretty much). My main cross section and framing lines are usually 25 - I use this one on many things; plan views and sections. I also print to PDF using 300 dpi; I get better results in the layout conversion to PDF at that setting (personal preference as most things are). If I were to go to 600 dpi I would use a 35 instead of the 25 for an average.

I think this may be part of the confusion (and fear?). Some may think the "active defaults" will go back to some OOB (out of box) original CA settings. The "active defaults" are simply the ones currently set. That's what annosets did - change the active defaults. But SPV's also do that and much more as has been mentioned - a lot.

Is that wall layer "reversed" by chance? Check the plan file at that wall and see which side the siding is on. Just a wild guess without a plan file.

Did you check with the originator to see if they were ever created in the model?

My current method.

Anyone know why the emoticons are still screwed up? Is it just my system? No big deal, but they have been this way for a while.

Good chuckle for me this morning. Thanks.

I totally agree. I know training videos are not cheap to make, but the benefits, from an education and PR standpoint, would go a long way to help users, especially new users and those contemplating moving to this software. I think much of the confusion on "Saved Plan Views" (SPV's) could be avoided if CA put out a good video explaining why annotation sets are being replaced with SPV's (which do the same thing and much more as Steve mentioned) and how to set them up and use them. Many people are visual and a good video just might get the light bulb to light up on SPV's and eliminate some of the obvious confusion that still exists.

Sometimes those little white boxes are your friend. I use them to make my dwgs more "professional." Just a different way of looking at it, I guess.

Amen to that!

@glennw Typo, Glenn?

I've been following this thread out of curiosity mostly, until I realized I might do the same thing in the future. My 2 cents is to recommend you contact Tech Support again with a reference to this thread in order to give them the scenario Michael came up with and the confirmation it can be repeated. Kudos to Michael for his diligence.

I think he secretly works for CA but is just too humble to admit it!

I like to use my main (modified) Architectural toolbar "floating" with the child toolbar close to it and move them around if necessary. I had to stop trying to use it when using sections, which I like to move to another monitor, because the toolbars always "goofed up." They would change from floating to attached, sometimes on the right side of the main screen, sometimes at the top of the screen. Pain in the butt for sure. Toolbars should just "stick" when you float them instead of CA deciding they need to be somewhere else on the screen(s)' real estate. Most of the time I don't lose them, just have to hunt for them where CA put them.

Same here. Never could pinpoint what caused it to happen. Closing CA and reopening sometimes brought them back, sometimes not. Frustrating when it doesn't.

Looks good, Eric.