Joe_Carrick

Depending on the area (Fire Danger, Possible Freeze, etc) foundation and attic vents may need to be auto closing How do you handle those conditions? It would be great if there were Symbols for those specific types of Vents.

I have a macro that can be placed in a Note to display the number. Actually the Macro generates a number composed of the floor number followed by the schedule number without the "R". I will post that macro tomorrow.

I think it's a system cursor setting. There should be several sizes available but I'm not sure where to find those on your system since you are using a MAC. On a Windows machine I right click on the desktop and select Personalize - then type "cursor" in the "find a setting" search box

X11 has provided a lot of new attributes that allow listing of the layers within assemblies. However, for the average user it might not be very easy to utilize them so I created some macros (all named starting with "layers_") These will work nicely in Labels and in most cases with Leader Line Text. They work especially well in Plan Views - not always in Elevations and Sections. To get the best results the finish materials and structural materials in the model should be named carefully. As an example: SLAB FLOOR STRUCTURE (material descriptions) Concrete Slab with 6x6 10/10 WWF 6 mil Visqueen Membrane Sand Base Framed Floors will of course have different materials and thicknesses. Of course you also need to specify the corresponding material thicknesses to get the sections to be accurate. It may take a little time to create/rename various materials and to use those materials in your plans in order to get the best results. But that is time well spent when it improves the annotations in ConDocs. Let me know if you have any questions about using these macros. If you are inclined to contribute to my efforts, please deposit a contribution in PayPal account chriscoll@dslextreme.com Layers Lists - X11.json

Larry, It only works if you change the "My Data Folder". There's currently no way to change just the "Templates" Folder. Yes, you will need to copy the old data folder to the new location before change the Preference. The old data folder will still exist but it will not be accessed. Note that making this change will effect all the subfolders as well and they will be synced across all your systems via Dropbox.

Larry, I just copied the Chief Data folder to my Dropbox location. Then I set that location in Preferences. Then whenever I open a template that's where Chief looks for it.

Basically, you can't have a higher ceiling height because a room above has a floor height that's to low to allow the higher ceiling. Raise the Floor above and then you can edit the ceiling below. It's best to work from the top down so that you avoid this kind of conflict.

It would be appropriate for these requirements to be available in the Framing Defaults. ie: User specified with an OOB default matching Table R602.7.5 Note that for energy purposes the studs are often 2x6 or greater so the actual structural need may be less than what Table R602.7.5 specifies. I do my own structural engineering to determine what is needed for wind loads as well as gravity loads. Depending on the location of the header vertically vs the height of the wall that can vary dramatically. Also, when using Simpson Strong Walls that Table isn't appropriate so even if CA adds the requirements to the Framing Defaults they should be able to be over-ridden.

I'm not sure exactly what you are saying. If you right Click on the "Library" tab of the main menu bar (this is not a "Tool Bar") and the "Library Browser" shows a check mark then it should be visible someplace. Another way is to move the mouse cursor over the "View" tab you will also see if the "Library Browser" is checked. If not, click on it to make it visible. "Library Icon" is something I don't understand - as far as I know there is no such thing in Chief. BTW, what version of Chief are you using?

Hi Michael, Yes, I have also adopted that methodology - for certain cases. However there are limitations when more than one object is in that position in the schedule (multiple copies of a Note for example) and you need to accumulate values. In that case, you may need to store several sets of data by using a multi-dimensional array. It can get complicated. That's why I made the suggestion of being able to access the displayed Schedule Content from within a User Macro. That would make it much easier.

That's because X11 is still in Public Beta - or your SSA isn't current. If your SSA is current the Public Beta of X11 should be in your digital locker.

You should also check out X11. There are some really great new features regarding Textures and Patterns - including offsets as well as auto pattern generation from texture.

No, Chief Architect Version - which in my case is: X11 (64 Bit) or the full name: Chief Architect Premier X11 (64 bit)

No, because there's no way to get the data from the Schedule. The only way to accumulate areas is to utilize the Room Labels or the Label of Polylines. It can be done with a macro but it's not easy to do because it's a running total and has to be reset periodically so the same areas are not added repeatedly. That means setting a timer to limit when the label macros update the data is critical.

Yes, I know that but I'm not sure why this needed to be done. Was it primarily for the Materials List? Note that the Ruby Tutorial is a method that's loaded by Chief at startup. This is created within an "rb" file using standard Ruby "method definition". As I stated previously, any methods that need to be created can (and IMO should) be done specifically as Class Methods by defining them as such.

Please send me a PM with a more detailed description of what you want.

I am pretty sure that would work - but I just prefer to use the model itself as the data source. I set a timer on my data accumulation macros so that they stay updated properly.

In order to do ventilation area calculations using macros (which I have done) it requires that you: Collect the total areas of Crawl Spaces, Basements, Garages & Attics Collect the total areas of all Vents and they must be identified as to what type they are The Types would correspond to the above listed spaces The Types can be based on room names containing specific words. All of the above can be done using macros within the Labels of Rooms & Vents. The calculations of required vent areas may vary depending on the locale. The NFA is dependent on the vents being used and as such need to be plugged into the macros that display the required and actual vent sizes.

Note that this is in reference to Classes must start with a Capital. User Macros are not generally: Classes which must start with an uppercase character Methods which must start with a lowercase character Constants which must start with an uppercase character In fact, a User Macro is just a Ruby Script that uses Ruby Classes and all their Objects. It can even start with a special character such as the underscore. I'm not sure how Chief's implementation of a macro as a method would fit in that scheme.

Hi Kirk, I just reviewed both of those links and neither of them specifically identify a required upper/lower case requirement. As far as "methods" are concerned, I use define them as Class Methods as the first link shows. User macros that act as "Methods" would still need to be used carefully within other macros simply because they need to belong to the same "Class" and that requires the user to understand that fact. IOW, a "Method" that performs math calculations must use variables that are limited to numeric values and one that performs string manipulation must use string variables, etc. Ruby already includes virtually all the Classes and corresponding Methods such that defining additional macros to act as Methods is just not needed. I would be far happier with Chief providing all the Object Properties as available attributes. X11 has improved this with the groups (arrays) for Walls, Floors, Ceilings and Roofs, etc but there are still hundreds of values we can't access.

Kirk, AreaRounded or RoundedArea will also still work so long as the object the macro is evaluating has a readable area. I just don't like the software unnecessarily forcing this on me. It's OK to tell me (with my ability to over-ride the message) but it's not cool to force a convention that I don't want.

Basically so that the annotations (dimensions, text sizes, arrow sizes, etc) would be what you want automatically. Of course, you can have defined Annosets and Layer Sets to switch to, making that happen. So the only real advantage would be the elimination of a couple of mouse clicks.

FWIW, I now name my macros using lowercase but almost all of my existing macros (several dozen) were capitalized and in I retain those names - even when I make edits. When I need a "method" I define it as such in an "rb" file which can be loaded and is then available for use within any other macro.

Renaming isn't really mandatory. If you do allow Chief to rename them then everyplace you have used the Uppercase version will no longer work because that macro will no longer exist. When Chief asks (suggests) that they be renamed - I just select "Ignore". It's only in cases where you want to call a macro from within another (as a "method") that it needs to start with a lower case character. For me, that's almost never. BTW, I think when CA initiated this "Renaming" it was a big mistake. It's a real PITA to deal with. Ruby is case sensitive and conventionally uppercase is supposed to be reserved for "Constants" it isn't mandatory to make everything else lowercase..

I can see how it would be useful - and I would probably use it. OTOH, I generally just select the desired Annoset immediately after creating a orthographic view and save the camera. It would be nice if that wasn't necessary.