Alaskan_Son

This is correct. Any changes to your default settings will affect only that one plan. Any changes to your Preferences will affect Chief's behaviors with all plans. In addition, Default settings are basically plan settings whereas Preferences are program settings. I would word this a little differently. Global changes affect every instance of that version of Chief that you might open up on that machine...old plans, new plans, etc. Per the Help files, they "apply to all plan and layout files and are preserved between sessions". Changes to the Default Settings in your Plan Template are still file specific. They only change the settings in that one single plan file. They will initially affect all new plan files that are created using that template, but every single one of those new files will have it's own unique settings from that point forward. No Default settings in any plan (template or not) can affect the default settings in any other plan. It only seems that way if you use an existing plan as the basis for a new plan. The new plan just starts with those settings though...they're still not global.

Try starting with Tools>Toolbars and Hotkeys>Create Hotkey List That will create an HTML file. Open that file and see what it shows for assigned hotkeys and test those out.

That's what the NumberFormatter is for.

Where are you seeing this as a "default display"?

That was just copied and pasted from Eric's code. I use this type of formatting for all sorts of things actually. Most importantly though, regardless of what I am ultimately displaying, I still want precision. I may or may not ultimately put 7.23" on some drawings, but I want to know that's what the number is, and I want to use that number in any calculations.

I don't think the example was using Eric's code at all. And I didn't disect BT's code that far. It looks at least a tad over-complicated though and a bit too dependent on the automatic label. When setting up custom labels like this, I find its typically best to build them from scratch for the desired use, using only the source values (schedule_number, width, height, and type_code in this case), and keeping them as simple and as explicit as possible. In this case, the desired label formatting could pretty easily be accomplished in as little as a single line of code and without all the unnecessary error handling...although I would likely use about 3 lines of code. EDIT: I took a quick look at BT's code and it looks like the problem is almost certainly the result of the conversion of a text string to an integer. .to_i converts only leading numerical values to an integer. If there are no leading numerical values, than the result is zero.

Typically the only thing you have to do to ensure your code will work in both X12 and in older versions is explicitly convert your desired object attributes to floats. So, your macro would just need the last line to read... ConvertToFeetInches(height.to_f,16, "-", "-", true) + "x" + ConvertToFeetInches(width.to_f,16, "-", "-", true)

You were right the first time. It didn't work because there was an error in one of the lines that BT fixed in the follow-up sample plan... dim = $FtIn.apply(obj.width.round(0)) + "w x " + $FtIn.apply(obj.height.round(0).to_s) + "h" #You can't apply the X12 NumberFormatter to a string

Kinda depends on the project I guess, whether it’s something you might use on future projects, on whether or not you have to custom order each pull size, on how many cabinets there are, on what the likelihood for changes is, etc. etc. I could go either way.

This of course could be done as well, but some of the other options could provide for automated sizing.

Yes, but I likely would not be applying them as pulls, but instead apply them as either a separate face item or an accessory. Ya, probably an accessory of one type or another attached to that face item. Could also be done just using custom door and drawer panels where the pull is an integral part of the door/drawer front itself.

Use another framing member and either the Trim tool, the Extend tool, or the Join/Lap tool.

Just sent you a PM.

The height/radius on one of your roof planes isn't actually correct, but that's not what's causing your problem. I'm not 100% sure, but I think what you're seeing is just the result of some hardcoded facet angle limitations. I wouldn't worry too much about how it looks right now. I think if you keep going through the process, you should still end up with the desired results. Having said that, you may need to tweak things a little for your specific plan sometimes anyway. For example: I've found that you may need to shift the start and end points of your manually drawn valley so that they snap right to the corner points (wall and peak) instead of to the line created by your CAD Detail From View. In addition, your ceiling planes could be such that they don't actually create any usable linework at the valley prior to that CAD Detail From View Step. In those cases, try temporarily changing the material being used for your ceiling to get some additional snap points. In fact, this may be preferable anyway since it results in a nice uniform snap interval...

Yes sir. I did. Chief is a little finicky in this regard, but yes, you can get the ceiling planes to clean up decently well in 3D but... -It can be very difficult to accomplish for even a single edge. -It becomes exponentially more difficult to accomplish for multiple edges. -Perhaps most importantly, it requires shifting edges and moving planes so that the results become quite inaccurate in other views--particularly Plan View. It's just not worth even going down that road in my opinion.

Preferences>General>Startup Options. Make sure this setting is unchecked...

It's definitely related to the room and it's something we run into with PBR all the time and one of the many reason I still prefer Ray Traces. Chief just treats object differently depending on whether they're in the room with the camera or not. Even those columns. The reason they're getting lit differently is because 2 of them are facing the exterior and one is facing the interior and as such, Chief is treating them as belonging to different rooms. A similar thing commonly happens with other objects such as doors depending on which room Chief sees them as belonging to. Anyway, don't have time to offer much in the way of solutions right now, but wanted to at least point a couple things out.

My thoughts exactly!! I was thinking of writing up a post and was relieved to find I didn't have to.

No. All I'm talking about is the ability to hover over a drop-down and then scroll through it with the mouse wheel or arrow keys.

Here's a 3 part video series I made on the subject a little while back. I would really recommend watching all 3 even if the first one solves your problem. There's some good information in there....

Yes, but not sure you'll like it. My suggestion is to start a new template from scratch. I see a lot of pervasive problems caused by the insistence on working with an old template instead of starting fresh. You just keep carrying issues forward, and as you've found, it can be very difficult to sort through some of those things. I say its best to stop fighting it and just start a clean new template where it only includes things you need and settings you (in your more experienced and knowledgeable state) have very purposefully set. If you do decide to stick with your old template, in addition to system layers, multiple saved defaults, and other default settings, there's at least one more place layers can be used that I don't believe was mentioned, and that is in CAD Block Management...particularly if you have "Automatically Purge Unused CAD Blocks" unchecked.

I don't believe this is accurate. If you actually find this happening, I would report it.

I remember very clearly because it’s a feature I actually made use of, and it really wasn’t very long ago. I believe it was removed in X9. The ability we had was the option of naming layers differently in different layer sets and it allowed for a good handful for things such as: -The ability to share files a little easier when one user preferred a totally different naming convention. -The ability to use AIA naming conventions for any given layer set. -The ability to append/prepend a layer name with a code to describe its intended settings in that particular layer set so that you could make temporary changes and then quickly filter (using code), group select, and then toggle accordingly. -Some macro capabilities I won’t get into that Chief ended up very effectively replacing with some other feature improvements. Anyway, I thought I t was a useful feature but I do agree that it was problematic for most users.

Can you make a quick video demonstrating this so called “glitch”. It still sounds like you’re describing a completely normal behavior. Just because you’re doing something on accident doesn’t make it a glitch.

I think you’re probably remembering the ability to RENAME layers differently in different layer sets.