Alaskan_Son

I took a quick look at that Pella macro this morning and it seems to have a handful of problems. In addition to the issue with the new Measurement class, there's also an issue with their use of the word "label" which currently conflicts with the name:value pair using the same name (an attribute that didn’t exist when the macro was originally written). There are other issues as well but I don't have the time or inclination to figure out what those are. For now, see if this modified version of the macro will work for you. Just DO NOT Migrate it. Leave it using the old deprecated behaviors. Pella quick mod.json And please report to Chief so they can incorporate a proper fix.

Carefully read the advice given by @rgardner and @JacobB given above, but if some nuance about how you're doing things still requires or otherwise results in those fractional values that you don't want to see, you can always using the round method to round your values: %schedule_number% - R.O. %width% X %height% %type_code% SH %bottom_elevation.round% - HH %header_elevation.round%

In addition to using Defaults and Style Palettes, you can also change one cabinet and use the Material Eyedropper/Painter, the Object Eyedropper/Painter tool and/or Match Properties.

Yes. Chief doesn't work this way and they have yet to provide any setting that allows us to do so. The best replacement option that I know of continues to be the method I mentioned earlier in the thread: Again, you can customize your hotkeys if desired to make the operation easier, but the basics are the same.

Your best bet is to just turn the arrow off and place one manually.

You are completely correct. The Structure setting does (or at least can) indeed affect other things in the model--particularly if you are lowering the roof so that the bottom of the defined structure starts to encroach into the ceiling and wall framing below. I corrected my post to reflect that. I guess I've very rarely had to lower any of my roof planes. I'm almost always making them higher so the Structure settings don't affect much of anything. I should have known better. Anyway, thanks for bringing this up. I stand corrected. The Structure depth should be changed if you're trying to lower a roof after it was initially built using the wrong settings. I'm not sure it matters if you're going to raise the roof, but as a matter of good habit, it should probably be changed in either case. Thanks again. Good catch.

Yes. I do this exact thing myself. Here are a couple examples with visuals: One option is to do as @Kbird1 suggested and just set you Drawing Sheet to be 22"x34" in Layout, but when you print, simply select Check Plot at>1/2 Scale: Example using 24x36 and 12x18 but same exact principle applies: If scale doesn't matter, you can also do as @VHampton suggested and simply use Fit To Paper. I would however note that the percentage completely depends on your title block and borders. For me, 100% works just fine for printing 24x36 to 11x17:

If a person is going to use trusses, then the Structure thickness won't even matter. It's all about setting the Baseline Height correctly. For existing roof planes that were initially drawn using the incorrect settings, I can think of at least a few options, but in all cases you are correct that the Structure Height should be changed to match the correct Truss Top Cord Depth. Check Trusses (no Birdsmouth) in your Roof Defaults, draw a new roof plane, open it, copy the baseline height, delete the roof plane, open your other existing roof plane(s), Lock Pitch, and paste that baseline height into the baseline field. Open another existing (but correct) roof plane, copy the baseline height, open your incorrect roof plane(s), Lock Pitch, and paste that baseline height into the baseline field. You can draw a truss, take a section view and simply measure how far your roof plane needs to move. After changing the Structure Depth as @Chrisb222 suggested, inspect the Vertical Structure Depth on the General tab. Lock pitch, and set the Baseline Height to Top of Plate+Vertical Structure Depth.

This isn't quite right (or its at least an incomplete picture). Changing the structure setting in Roof Defaults will only cause the roof to be lowered for newly drawn roof planes. It will not however affect any existing roof planes and even newly drawn roof planes will get set at the wrong height since rafter framed roofs get the baseline height set differently than it would if Trusses (no Birdsmouth) were checked.

@Chrisb222 already pointed out the main issues, but to clarify a bit: First thing to understand as that when you check Trusses (no Birdsmouth), 2 important things happen: 1). Chief changes the Structure Thickness to match your Default Truss Top Chord Depth. 2). Chief automatically places the Baseline height of the roof so that the bottom of the Truss Top Cord sits right on top of your wall at the Baseline. The above is true for BOTH automatically generated roofs and for manually drawn roofs (assuming you change the setting before manually drawing your roof). You can find all this information and more if you get into the habit of clicking the Help button. In this case, open the Build Roof dialog, click the little Help button down in the corner, and read up on the Trusses (no Birdsmouth) setting. Follow any related links if you don't find what you need in that particular article.

This is true, but upon creation of a new elevation that uses those variables, the user is almost certainly going to be copying other stuff anyway, Might as well just group select that item as well. Regardless, it only takes a matter of seconds. Depending on the approach taken, the macro(s) could even be placed in a default label or default text box thereby alleviating the need to copy anything. Your suggested approach (using a Global hash with a unique key set by the user for each new plan) will work as well, but in large part, you're just kicking the can further down the road. Not only does each user have to remember to change that key with each and every new plan and for each and every new plan iteration, but they may even need to change it for each and every user. PLUS, the global hash would never even get populated until the CAD Detail were opened up. That means for every single session for every single plan, a person would have to first open that CAD Detail if they wanted to see the appropriate values. The bottom line is that if you're going to be using Global variables, you'll get the most stable, consistent, and predictable results if the macros that define the variables can be placed in the views that are using the variables. This isn't always possible, but when it is, I would highly recommend doing it. All other approaches rely on shutting down and restarting Chief, shutting down and restarting plans, opening specific dialogs during various operations or during each session, opening or scrolling through specific views in each plan or session, and/or maintaining some other complex routine to ensure accuracy.

Here’s one method that doesn’t require any macros:

By the way, you can also skip the use of Globals altogether and simply use a hash: Example Hash: name: test value: {:a => 1, :b => 2, :c => "apples"} Example Usage: %macros.test[:a]+macros.test[:b]% %macros.test[:c]% #=> "3 apples"

Just so you know, there are plenty of other solutions that haven't even been discussed. For example, why not place all these variable assignments into a single Parent macro? Set that macro to include nothing as its last line ("" or nil) and then wherever you want to use one of the variables you simply place both the Parent and the Child. Example: "parent" macro definition: $a = 1 $b = 2 $c = "apples" "" Placed into your desired label, note, callout, or text box: %parent%%$a+$b% %$c% #=> "3 apples" or one of several other optional formats; %macros.parent; "#{$a+$b} #{$c}"% All your assignments are made in a single place and because the parent macro is always placed with any child macros, the results are always accurate. You could also define Classes and Methods like so: "parent" macro definition: class MyClass def a 1 end def b 2 end def c "apples" end end MyClass.new Placed into your desired label, note, callout, or text box: %macros.parent.a+macros.parent.b% %macros.parent.c% #=> "3 apples" Again, all your assignments are made in a single place, and even though Classes and Methods are global by nature as well, they will always be accurate per the current plan because you're referencing the defining macro in every location that its being used.

No, not at all. Read my post again. Specifically this part... You place the required macro(s) into the required views in your template plan. Once and done. From that point forward, all you do is change the CAD Block or macro definition in a single place and any/all views that use any associated global variables will be updated as well. Because the defining macros live in the views where the variables are being used, the variables will always be accurate.

You've highlighted the key issue and that is this. A global variable must be properly defined before you can use the desired value in any given view. In my opinion, the best way to ensure this happens is to include the variable defining macros in any view that they are being used in. They can be placed off to the side, they can be made invisible, they can be made super small, they can be hidden...any number of things, but if the macros that set the desired value are placed in the same views where you are using the desired value then you'll always have the most current value as it pertains to that particular plan. In the specific scenario mentioned by the OP, that whole setup can potentially just be part of a CAD Block. That CAD Block can simply be dropped into any view where the macros are used. Update the CAD Block, and all views that contain the CAD Block will be updated as well. Yes, there are various other methods of dynamically naming or organizing variable values so that the value is linked to the specific plan. You can use the actual plan name, you can make a habit of incrementing a unique plan number with each new plan, you can simply copy and paste your macro definitions from a spreadsheet that assigns unique names to your variables, you can use macros that reference an external file (that again uses unique variable names for each plan), and so on. I personally don't think however that its worth jumping through all the hoops when you can just make sure your global defining macro(s) are present in the views where the values are being used.

They don't actually jump from one plan to another. The issue is simply that there's only one global memory to go along with any given instance of Chief. So, for all intents and purposes, any global variable can only have one value at any given time.

As some of the others have already pointed out, what you're talking about is actually a global variable, not a global macro. It would help if you were to communicate in the approrpiate terms. Chief does have some of what they call global macros, but those are a different thing entirely.

…or your “Walls, Attic” Layer is turned off.

It did at first, but the more I thought about it, the more I realized that it wouldn't actually change my current workflow hardly at all. The offset would vary based on foundation type, sub-floor thickness, and joist depth at a minimum meaning I would almost certainly end up having to manually change that number for every plan anyway...which in turn means that I might as well just manually change like we already have to now. If you're always working with a flat lot and always use the same foundation/garage slab, joist, and subfloor specs, then you might as well just change that Subfloor Height above Terrain setting in your template plan. Again, just like we already can. If you're dealing with a sloping lot or dealing with multiple garage slab heights than there's no way around it, you would need to set differently for each individual scenario. Bottom line, I can't think of any situation where I wouldn't still be going through the same number of steps with or without a manual offset setting.

You bet. I’m suspecting you just didn’t click on the link. The title doesn’t make it very clear that it’s going to describe what you were looking for.

Click the Help button while you're in that dialog and then follow the link. You'll find this: "The program automatically positions Floor 1 a set distance above the terrain. To do this, it first calculates the average elevation of the building footprint's perimeter and then assigns that average elevation to the center point of the building footprint. Finally, it adds the thickness of the floor platform to this value . If a foundation is present, it also adds the thickness of any sill plates plus either 6” (150 mm) or 8” (200 mm) depending on the foundation type. The resulting value, referred to as the automatic Subfloor Height Above Terrain, is how far the default height of Floor 1 is above sea level in the current plan. See Foundations and the Terrain."

I'm all but certain that the OP simply converted to the wrong symbol type based on the last sentence in the post... If I were a betting man, I'd bet that Robert already pointed out the most likely culprit...

A few notes: Here's what you typed up... %automatic_label.Slice!(%automatic_label.index("-")+2..60% This would have actually worked just fine except that you had a number of small mistakes. What you should have typed was.... %automatic_label.slice!((automatic_label.index("-")+2)..60)% With corrections marked... %automatic_label.slice!((%automatic_label.index("-")+2)..60)% Having said that, and although it will work, I would suggest a few other things about this approach... Using slice! instead of simply slice isn't really necessary in this situation. It's not hurting anything, but it serves no purpose in the context in which you're using it. To take it one step further though... You don't even need to use slice at all. The string[index] method will actually do the same thing. Using an extra large index (60) to make sure you grab all possible characters is a sloppy way of doing so. You should really use -1 which represents the last character in the string. So a cleaned up version of your same general approach with changes would be... %automatic_label[(automatic_label.index("-")+2)..-1]% Anyway, as Eric pointed out, there are MANY ways of getting what you want, but I would suggest something I find to be a bit more succinct and explicit. That is, using partition(separator)... %automatic_label.partition(" - ")[2]% This method very deliberately breaks your string into an array containing 3 parts: a prefix, your defined separator, and a suffix. You then simply specify inside brackets which of the 3 elements you want.

There are a few keystroke sequences that will do the trick but what I normally use is Control+A (Select All) followed by Delete.